P.S.
Вот опять таки посмотрел статьи migera по ссылке из начала статьи — хорошая информация, но опять не про то как сесть и начать программировать конкретный код с конкретными эффектами конкретными инструментами, а больше справочная информация. Мне же хочется написать именно такую статью, что садишься за неё, а через несколько часов встаёшь уже с работающим кодом в работающей среде никуда больше не заглядывая особо.

А есть на примете какие-нибудь русскоязычные руководства в том духе о котором я пишу — чтобы от установки Nesicide и по каждому аспекту отдельно и нудно проходилось? Просто чтобы не писать одно и то же, а как то изменить точку зрения по сравнению с существующими аналогами.

Со времён этой заметки появилось ещё некоторое количество статей и на английском и на русском. Но писать всё равно стоит. Во-первых, время идёт, инструменты меняются, обновляются и устаревают. Во-вторых, иметь варианты всегда хорошо, не пошло дело по одному гайду (автор непонятно объясняет, читатель почему-то не понимает) — хорошо иметь другой. Ну и просто лишнее напоминание публике о том, что есть такая возможность, писать под подобные старые платформы.

Начал сам знакомится с программированием на ассемблере через Nesicide уже пару вечеров и уже начало получаться и начала складываться картинка как оно вообще происходит, что за куски памяти и сегменты описываются в одном файле, судя по всему начинаю уже догадываться как их натягивать на мапперы и на экране символ уже инкрементируется в цикле, после GBA в принципе это уже конечно детали и тонкости.
И вот тут возникает вопрос — есть смысл писать на русском введение в программирование на NES по лекалам как я написал про GBA — от скачивания среды и через поэтапную реализацию всех нужных техник для создания игры или что-то такое уже есть? Есть ли на английском даже — и то вопрос?

наоборот — у процессов разные стеки и регистры, а вот память как программ так и глобальных данных общая, поэтому нельзя модифицировать код или полагаться в работе на перезаписываемые глобальные переменные.

поконкретнее, что не нарушать-то? стеком не баловаться, альтернативные регистры не применять?..

я просто хочу протестировать наколенную реализацию вытесняющей многопоточности и для этого нужно выполнить требования выше — чтобы два потока могли исполнять один и тот же код синхронно. а всё что гуглится либо для скорости оптимизировано до нарушающих многопоточные принципы оптимизаций либо не гуглится вовсе.

давно делал и компактные варианты, можно поискать в закромах

P.S. пункт (г) не означает что режим записи должен быть входным параметром в алгоритм — можно добиваться этого просто модификацией кода или созданием трёх разных процедур. главное сама принципиальная возможность — почему это вообще важно, потому что уже упомянутый fast divide & conquer line часто пишет пиксель по два раза и поэтому на инвертированную линию без серьёзных модификаций просто не способен. тут важная сама принципиальная способность делать это точечными изменениями кода.

Господа, тут такое оживлённое было обусждение сверхбыстрого алгоритма рисования линии, что осмелюсь тут спросить: ни у кого не завалялся исходный код рисующий линию по брезенхему удовлетворяющий следующим условиям:
а) рисует линию от начала до конца (а не легко гуглящийся fast divide & conquer)
б) не использует глобальных переменных кроме констант типа предрассчитанных таблиц
в) на самом деле то же самое что и (б) — не использует самомодификацию кода
г) способен писать как 0 так и 1 так и инверсию
д) легко скопипастить в другую программу
Суперскорость не особо нужна, думал легко найду, но ни на русском ни на английском гугл как ни мучаю — ничего подходящего не вижу…

В статье упоминается, что Zilog сперва хотела продвигать другую архитектуру — дело в том, что в 1979 (всего через год после выхода в продажу Intel 8086) году фирма выпускает еще один процессор Z8000 уже несовместимый с Z80 с продвинутой 16–битной архитектурой: 16 регистров общего назначения, множество режимов адресации и до 8 Мб сегментированной памяти. Интересно, что когда IBM захотела покусится на нишу персональных компьютеров и создала IBM PC Z8000 уже был на рынке и гипотетически мог быть выбран в качестве сердца новой машины, но IBM выбрала процессор Intel и если верить википедии:

Федерико Фаджин, тогда исполнительный директор Zilog, считает, что причиной тому было то, что владельцем Zilog преимущественно был один инвестор — Exxon Enterprises, фирма которая имела амбиции конкурировать с IBM. Поэтому когда IBM начала проект PC она рассматривала Zilog как конкурента и выбрала Intel 8088, а не Z8000 потому что не видела в Intel конкурента на рынке компьютеров.

Позднее Z8000 обзаводится 32–битным наследником Z80000, но это уже не помогает — звезда Zilog на рынке персональных компьютеров закатилась окончательно и сейчас фирма занимается микроконтроллерами.
Интересно каким был бы современный мир домашних компьютеров если тогда давным давно IBM сделал бы выбор в пользу Z8000. :)

Естественно, что никто в здравом уме не будет показывать демо вместе с Tiny MP3. Все-таки новое качественное демо на спектруме не часто случается. И если это случится, наоборот нужно как-то это акцентировать. Как-то наиболее выгодно показать.

Я хочу донести мысль, что внеконкурсная работа не имеет никакого отношение к конкурсной программе. На пати вне конкурса проходят самые разные движухи: семинары, выступления музыкантов, капоэйра в конце концов. Но никто же не требует, чтобы его капоэйра была обозначена в правилах конкурсов.

Хочешь свою капоэйру? Не вопрос. Предлагай, согласуем, как это лучше показать. Но просить внести дополнения в правила конкурсов по своей капоэйре на мой взгляд дико.

с нюком не все могут быть иногда согласны но нюк всегда прав :)

Андрей, ну в общем конечно понятно, что Денис тебя провоцирует, и что сознательное смешивание маринования с внеконкурсом — как бы аргумент дохлый. Но, тем не менее, ответ немного странный. Поясни пожалуйста, из каких примерно соображений внеконкурсная работа может попасть в Tiny MP3? Потому что у меня в голове не укладывается. ОК, кто-то может захотеть хакнуть правила и заслать вне конкурса нечто неудобоваримое, что не вписывается в демокомпо? Но почему тогда не бороться с этом преселектом? Совсем чётко: какой вообще может быть резон держать внеконкурсные работы вот прямо настолько второсортными?

Я.

А кто будет отвечать за показ?

Ну т.е. демо-маринады можно показывать в одном компо с демами, а те что вне компо «не гарантирую». Понятно, спасибо

Можно.

Я не могу гарантировать, что работа не будет показана первой. Или девятой. Или во время Tiny MP3 compo. Это уж как решит человек, отвечающий за показ.

Но показана будет. Голосования не будет. Места не будет. В паке работ будет. Или не будет, как решит автор.

Можно снять на видео, как ты публично отказываешься от участия в компо и голосовании.
И выставить его в вайлд!

Ничем