Разработка программ и игр для ZX Spectrum на языках Оберон-семейства

[alone]

Да не будет уровень технологии на Спектруме расти, и будущего у Спектрума нет.

Будущего нет у процедурного программирования. Скоро будут процессоры с 1024 ядрами, под которые можно писать только на функциональных языках или на чём-то, что ещё не придумали. Или вообще откажутся от понятия "ядро" и будут программировать на верилоге.

[jerri]

alone, да да будущего нет доживем до декабря 2012 и посмотрим

[Eltaron]

чем тебе не сдвиг?
да да совсем старый на грязи надо ехать отдыхать - привыкать

Пардон, это же сложение? А я и писал именно про то, что сложения быстрей сдвига. Для байтов - add a,a - 4 такта, sla a - 8 тактов.

[alone]

Если нет разницы, то зачем платить больше?

[Andrew771]

Для байтов - add a,a - 4 такта, sla a - 8 тактов.

вместо sla a лучше rlca.

[jerri]

Eltaron, а чем тебе add hl,hl не сдвиг влево?

[Error404]

Error404, и много ты сложных систем на Спек пишешь?
я смотрю для спека все системные программы практически написаны

Для именно Спека я не пишу ничего.
Для Ориона пишу и на асме и на С. Большая ли разница в писании под Орион и Спек - вопрос религиозный. Портирование стека TCPIP из исходников на С у меня заняло примерно 40 часов (месяц вечерами). Напишешь ты за 40 часов сетевой стек на ассемблере? Можно не отвечать, вопрос риторический.

С другой стороны, CP/M я правлю на асме, (хотя оригинал был на PL, кстати), и это очень долгий процесс - на асме проще наделать ошибок и сложнее отлаживаться.

Я конечно понимаю, что собственные шишки набивать, заново доказывая в 21 веке то, что уже считалось доказанным в 20м, это очень по спектрумистски, но тут уж давайте определяться: шашечки вам или ехать. Если дороже бесконечный и безрезультативный процесс, то пожалуйста - асм вам в руки. Если надо поиметь что-то реальное на выходе, то наиболее прямой путь - портирование. А с какого языка в код Z80 реально портировать, учитывая что на аcме Z80 ничего что нам хотелось бы, добрый дядя не выложил? Вопрос опять риторический.

[Eltaron]

Eltaron, а чем тебе add hl,hl не сдвиг влево?

ладно, уговорил действительно, этот машинный код можно было б и SLA HL назвать

---------- Post added at 15:51 ---------- Previous post was at 15:48 ----------

вместо sla a лучше rlca.

но там же в случае переполнения ерунда получится, а не умножение?

[Andrew771]

Сообщение от Andrew771
вместо sla a лучше rlca.
но там же в случае переполнения ерунда получится, а не умножение?

Если a<128, то нормально. Если a>=128, то и при sla a, и при rlca ерунда, т.к. результат уже двухбайтный должен быть (если использовать в ЯВУ).

[Oleg N. Cher]

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

Неа, пользователями этого языка, вероятнее всего, будешь только ты один. Я тут такую привлекательную картинку нарисовал: программь под что угодно на чём угодно, и то подавляющее большинство оппонентов против, а не за. Чего уж сказать про Паскаль. Кроме того, человек, который не знает асма Z80, вероятно, не будет писать игры для Спектрума ни на чём. И я предлагаю знатокам асма не замену асму, а просто способ увеличить собственную производительность там, где это можно без потерь (или с малыми).

Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X, а не использую специальную процедуру умножения на произвольное число

Андрей, но ведь запись X*2+X это реверанс в сторону тупого компилятора, а запись X*3, которая, кстати, нагляднее для понимания (и проще), но которую умный компилятор может перевести в сложения и сдвиги, что, кстати, SDCC делает. Что подтверждает и Eltaron:

sdcc команды умножения очень элегантно заменяет сложениями

Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.

Есть такая библиотека KOL, Владимир Кладов написал. Так она уже занимает больше мега исходников. Туда можно очень много добавить. Но программы, которые делаются на этой библиотеке, преимущественно размером < 100 Кб. Это очень реальный даже для Спека размер. Всё дело в подходе, потому как из KOL берётся только то, что используется. Примерно также можно сделать и с универсальностью. Да, у Спека экран устроен иначе, но в некоторых случаях для универсальности этим можно пренебречь. И пренебрегают, отсюда клэшинг атрибутов. Или ч/б вместо цвета. Всё можно продумать и сделать. Но очень трудно найти хотя бы 2 человека, которым на 100% понравятся все твои (или мои) идеи. Проблему я вижу именно в этом. А не в чрезмерной универсальности. Ну вот, спрайты Даша прекрасно себе чёрно-белые на Спеке и цветные под досом. Логика игры этот факт игнорирует, оставляя реализацию графической подсистеме. Разрешение экрана устройства она тоже игнорирует, манипулируя разрешением лабиринта. И так далее.

А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.

Я разве где-то предлагал такое делать? Всякому овощу свой сезон, а всякой задаче свой язык.

Ладно, давай искать точки соприкосновения дальше. Ты собираешься реализовывать ReadLn для строк и чисел? Если да, любопытно было бы взглянуть. Я сделал такую процедуру ещё на языке Coloss, и она позволяла редактировать введённое число только полным затиранием и перенабором, сейчас полагаю, это надо исправить. Нервы юзеров дороже. Нужно обязательно реализовать забивку (Backspace), курсор влево-вправо. Ещё есть идея реализовать память для прошлых введённых значений (вдруг новое число проще получить из старого путём изменения одной цифры) по клавишам вверх-вниз (примерно как было в досовской проге Doskey, очень удобно). Функционал буфера прошлых введённых значений можно сделать опциональным (нетрудно придумать задачу, где он не нужен). Согласен или предпочитаешь что-либо попроще (или другое)?