nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 06:00



Reply to topic  [ 94 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
Gigatron (компьютер на рассыпухе) 
Author Message
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Аппаратно устранить эту ситуацию можно двумя затратными способами: первый - укоротить цикл чтения
разными RC-цепями, чтобы он влезал точно в такт Gigatron-а, второй - отделить выход SRAM от
общей шины с помощью шинных формирователей, то есть: не пускать "хвост" на общую шину
по завершению такта чтения.
И то и другое требует аппаратного усложнения... :-?

Сработали, как ни странно, оба способа: сначала добавил шинные формирователи, но показалось,
что глюк кое-где проскакивает, после этого укоротил цикл чтения до 3/4 от оригинала, глюк исчез,
но посмотрел сигналы - от импульсов /WR пробивает иголоки на /OE ...
Attachment:
Glich.gif
Glich.gif [ 2.17 KiB | Viewed 13058 times ]

Возможно, если их убрать, шинные формирователи будут излишни...

P.S. Убрал, шинные формирователи, оставил лишь укороченный цикл чтения:
Attachment:
Glich2.gif
Glich2.gif [ 2.09 KiB | Viewed 13056 times ]

Глюка чтения из памяти нет, хотя иголки по /OE остались. Пусть пока так будет.

_________________
iLavr


06 Oct 2020 04:25
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
... идея, собственно, касается того, что в Gigatron-е при его оригинальной схемотехнике довольно
просто можно реализовать аппаратный стек!

В общем-то аппаратный недо-стек Gigatron-а практически процентов так на 80 близок к завершению:
Attachment:
GiG_SP.gif
GiG_SP.gif [ 23.58 KiB | Viewed 13056 times ]

В стековую область 0100H...01FFH четко заносится адрес возврата, сам стек сохраняется в Zero Page.
Глюк, связанный с чтением памяти, я устранил, значит считываться адрес возврата должен без проблем.
Осталось кое-что по мелочевке подчистить и будет Gigatron с аппаратным недо-стеком...

Недо-стек - поскольку отдельный регистр стека я вводить не стал, его функции там, где это необходимо,
выполняет регистр Х, содержимое которого сохраняется в Zero Page.

_________________
iLavr


06 Oct 2020 05:03
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
А кто-нибуть встречал динамичные не-текстовые игрушки на 2-строчном 16-символьном LCD-дисплее?

В LCD можно свои шрифты произвольные загружать и воспроизводить подобие анимации...

В Proteus есть такой пример:
Attachment:
LCD-GAME.gif
LCD-GAME.gif [ 8.99 KiB | Viewed 13009 times ]

Рот с палкой, которого они называют "Пэкман" съедает текстовую строку. :wink:
Attachment:
4_Bit_LCD Driver.zip [19.33 KiB]
Downloaded 286 times


Я погуглил и нашел одну игрушку такого плана - на Ардуино:
Attachment:
25940574.jpg
25940574.jpg [ 70.16 KiB | Viewed 13009 times ]

Игра называется "Hill Run 2". 8)
Quote:
Задача играющего - перепрыгивать через горы, а также приседать, когда мимо пролетают вороны. По горизонтали персонаж игры перемещается автоматически, игрок управляет лишь его перемещением по вертикали, поэтому кнопок всего две.
https://create.arduino.cc/projecthub/PunkyMunky64/lcd-hill-run-v2-runner-game-1b0523

Но что-то мне играшка не понравилась... Может кому встречались другие?

_________________
iLavr


08 Oct 2020 16:04
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
... идея, собственно, касается того, что в Gigatron-е при его оригинальной схемотехнике довольно
просто можно реализовать аппаратный стек!

Закончил я аппаратный недо-стек Gigatron-а, на первый взгляд - всё работает корректно,
но надо будет протестировать всё на каком-то реальном примере...

Пока делал недо-стек, просто забодал меня вот этот тупенький узел Gigatron-а: :twisted:

Image

Как изменишь тактовую частоту - так надо подобрать задержку, иначе - поплыла вся времЯнка... :evil:

Ясно, что на фиксированной тактовой частоте - это простой способ создать двухфазную последовательность
тактовых импульсов, и в Gigatron-е довольно жесткая привязка импульсов CLK1 и CLK2:
По фронту CLK1 - начинается такт и на шину выдаётся состояние одного из источников сигнала.
По фронту CLK2 - результат операции записывается в один из регистров.
За время между фронтами CLK1 - CLK2 должно успеть сработать самодельное АЛУ.
И, наконец, по спаду CLK1 - происходит запись в память, а чтение из памяти, как я ранее
выяснил всегда надо закончить до конца такта, воизбежание конфликта на шине.

В общем, выкинул я этот сомнительный узелок, формирующий CLK1 - CLK2 и приделал
нормальный формирователь двухфазной последовательности тактовых импульсов, где
все сигналы синхронно привязаны друг к другу:
Attachment:
Sync.gif
Sync.gif [ 3.73 KiB | Viewed 12966 times ]

Частоту тактового генератора, правда, пришлось увеличить вдвое, но зато узел позволяет теперь
формировать из следующего набора частот:
Attachment:
GEN.gif
GEN.gif [ 5.69 KiB | Viewed 12966 times ]

практически любые необходимые синхроимпульсы, что позволило убрать из схемы всякие задержки -
аналоги RC-цепей.

_________________
iLavr


10 Oct 2020 11:43
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Закончил я аппаратный недо-стек Gigatron-а, на первый взгляд - всё работает корректно,
но надо будет протестировать всё на каком-то реальном примере...
Lavr wrote:
Посмотрел я с этой точки зрения на неиспользуемые команды:
Image

Переделал я эти команды аппаратно следующим образом, вторая группа:
Attachment:
Tab_0.gif
Tab_0.gif [ 3.59 KiB | Viewed 12961 times ]

Это команды для сохранения РС в стек и сохранения самого временного указателя стека - Х в Zero Page.
Команда ST Y,[00,X] к стеку отношения не имеет, просто удобно в схемотехнику легла... :wink:

Из первой группы команд лишь две команды было сравнительно нетрудно переделать для извлечения
из стека адреса возврата:
Attachment:
Tab_1.gif
Tab_1.gif [ 2.15 KiB | Viewed 12961 times ]

Остальные команды - так и оставил неиспользуемыми...

Новая система команд и её аппаратная поддержка полностью совместимы с оригинальным Gigatron-ом,
но с помощью новых команд осуществить вызов подпрограммы и возврат из неё существенно проще,
нежели чем при чисто программной реализации стека возвратов:
Attachment:
Tab_3.gif
Tab_3.gif [ 17.41 KiB | Viewed 12931 times ]

Пока заметен один небольшой недостаток этого решения, следующие команды:
Code:
     ST  PCH,[01,X++]; - сохраняем в стек старший адрес
;-------------------------------------------------------------------- граница сегмента
     JMP Y,55Н; - переход к подпрограмме

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

Есть одна мысль, как устранить это аппаратно, хотя в принципе это не так уж и страшно для процессора,
в котором приходится следить за коротким переходами BRA в пределах сегмента, но попробую устранить
этот маленький дефект...

_________________
iLavr


10 Oct 2020 14:27
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Не стал я фиксить этот дефект - пусть будет фичей этого процессора. И у оригинального MOS 6502
похожие заморочки с пересечением границы сегмента были. :wink:

Здесь как ни крути, но в момент выполнения JMP программный счетчик никак не указывает на адрес
возврата, а указывает на команду после JMP, а её этот процессор в силу особенностей своей архитектуры
выполняет сразу же на адресе перехода, и лишь потом сам код по адресу перехода... :-?
Поэтому адрес возврата при возврате из подпрограммы приходится корректировать программно.

Если группа команд сохранения адреса возврата :
Code:
     ST  PCL,[01,X++]; - сохраняем в стек младший адрес
     JMP Y,55Н; - переход к подпрограмме
     ST  PCH,[01,X++]; - сохраняем в стек старший адрес
находится в одном сегменте, то стек вполне замечательно работает! :kruto:
Attachment:
GIG_SP.gif
GIG_SP.gif [ 23.48 KiB | Viewed 12931 times ]

Собственно за такими мелочами должен следить компилятор ассемблера, ведь даже у х86 компилятор
отслеживает адреса коротких JMP, и предупреждает если JMPS out of range.

В архиве - проект модели Gigatron-а с аппаратным недо-стеком:
Attachment:
GIG_SP.zip [97.45 KiB]
Downloaded 294 times

Вызовов подпрограмм там достаточно, а игрушку псевдографическую я писать не стал (хотя в коде есть
попытка начать
), поскольку на эрзац-ассемблере делать это неудобно, а хобби предполагает, что задача
решается с удовольствием. :P

Чтобы не писать длинных простыней, как стек приделан аппаратно, прикладываю также документ,
где всё подробно написано:
Attachment:
GiG_hSP.zip [448.24 KiB]
Downloaded 309 times

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

P.S. На схеме видно, что кнопка "7" зашунтирована переключателем - это для режима пошаговой отладки.

P.P.S. А жалко вобще, что я поздно внимание обратил на Gigatron, его перерисовать бы заново, чтобы
получился нормальный недо-6502 без ненужных костыликов. Ресурс такой у Gigatron-а есть!

_________________
iLavr


11 Oct 2020 14:56
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
А жалко вобще, что я поздно внимание обратил на Gigatron, его перерисовать бы заново, чтобы
получился нормальный недо-6502 без ненужных костыликов. Ресурс такой у Gigatron-а есть!

Обдумываю возможность реконструировать Gigatron в недо-RISC-компьютер принстонской архитектуры,
чтобы была возможность исполнять его собственную систему команд из ОЗУ, а ПЗУ команд включить в карту
памяти в качестве Монитора, ну или BIOS.

В чем смысл этой затеи: на данный момент из 256 команд Gigatron-а по меньшей мере 138 не используют
операнд в качестве второго байта. Конечно, стОит учитывать частоту вызова команд в реальной программе,
но так или иначе значительный объём ПЗУ команд пустует, поскольку у 138 команд из 256 аргумент чисто
фиктивный.

_________________
iLavr


17 Oct 2020 07:52
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Обдумываю возможность реконструировать Gigatron в недо-RISC-компьютер принстонской архитектуры,
чтобы была возможность исполнять его собственную систему команд из ОЗУ, а ПЗУ команд включить в карту
памяти в качестве Монитора, ну или BIOS.
В общем-то сама идея тут достаточно проста и понятна: если в ПЗУ команды и данные следуют друг за другом,
то в том случае, когда декодер командыControl Unit) обнаруживает код, которму необходимы данные,
то есть, двухбайтную команду, он должен перенаправить строб записи в регистр данных, а у регистра
команд
строб записи в этот момент заблокировать.

Честно говоря, это всё можно уложить в один такт, но есть одно усложняющее обстоятельство.
В существующей схемотехнике команда и данные появляются одновременно и за первую четверть такта должно
успеть сработать АЛУ
, поскольку после первой четверти такта происходит запись результата на выходе АЛУ
в один из регистров или аккумулятор. Этого не избежать - данные всегда проходят через АЛУ, даже если надо
всего лишь записать их в регистр или память.
Запись в память начинается с середины такта, так что временнЫе привязки в такте довольно жесткие.

Поэтому я решил ввести дополнительный такт для чтения данных в двухбайтной команде.
В этом случае диаграмма по тактам будет следующая: в начале такта код команды фиксируется в регистр команд,
программный счетчик РС при этом указывает уже на следующий байт в ПЗУ - следующая команда или данные
для текущей команды
.
Если декодер командыControl Unit) обнаружил код, которму необходимы данные (двухбайтную команду),
он блокирует импульсы записи в регистры и ОЗУ, и перенаправляет строб записи в регистр данных.
После того, как данное зафиксировано, выполняется обычный такт ЦПУ с этим данным и командой.

Аппаратно пришлось несколько схитрить, поскольку "вставить такт" схемотехникески получалось громоздко.
И я решил не "вставлять такт", а наоборот - "блокировать ненужный".

Схемотехнически получилось весьма просто:
Attachment:
SelDat.gif
SelDat.gif [ 17.81 KiB | Viewed 12803 times ]
Первоначально на выход ПЗУ подключены оба регистра - команд и данных, но запись в них осуществляется через
мультиплексор, которым управляет дополнительный D-триггер U8:A, включенный как счетчик до двух.
Если ничего не подключить дополнительно, то работать эта схема будет так: четный байт записывается
в регистр команд, а нечетный - в регистр данных.
Эту логику корректирует детектор двухбайтного кода U7:A (code detector). Для простоты эксперимента принято, что
команды типа xxxx.xx11b - двухбайтные. Поэтому детектор двухбайтного кода запрещает переключаться счетчику
U8:A
для всех команд, кроме двухбайтных.

Поскольку команда типа xxxx.xx11b - каждая четвертая, на осциллограмме видно, что лишь каждый четвертый
импульс CLK1
перенаправляется в регистр данных и блокируется для регистра команд.
Attachment:
SelDiag.gif
SelDiag.gif [ 957 Bytes | Viewed 12803 times ]

Если внимательно посмотреть проект:
Attachment:
SelDat.zip [20.24 KiB]
Downloaded 280 times

то можно увидеть откуда у данной схемы такая необычная фишка: выполнить команду после инструкции перехода JMP,
ту, что была прямо за ней по коду.
Дело в том, что счетчик типа 74LS161 - полностью синхронный, и когда выполняется команда JMP, на выходе ПЗУ
приготовлена уже
эта самая следующая команда. Команда JMP выставляет на входы счетчиков адрес перехода и
устанавливает разрещение параллельной записи, но счетчик 74LS161 - полностью синхронный, поэтому адрес
перехода
запишется в него только по фронту CLK1, но этот же фронт защелкнет в регистр команд тот байт, который
уже был на готове
, то есть байт, непосредственно следующий за командой JMP xxH.

Если применить счетчики типа 74LS193 (555ИЕ7), а я уже делал это в схеме для регистра Х, то этого эффекта
не будет - параллельная запись в счетчик типа 74LS193 - асинхронна, не зависит от тактовых сигналов и
имеет над ними преимущество.
Другое дело, что совершенно понятно, почему в оригинальной схеме применены счетчики типа 74LS161 - на высокой
тактовой частоте 6.25 МГц
все 4 счётчика РС переключаются строго одновременно, а счетчики типа 74LS193 - не
полностью синхронные
: при каскадировании имеют задержку на каждый корпус.
Но мне кажется, в данной схеме это непринципиально, поскольку считываем байт из ПЗУ мы всегда при установившемся
адресе
, и по этому же фронту счетчик увеличивает своё значение - к следующему фронту наверняка уже будет
стабильно удерживать адрес.

_________________
iLavr


19 Oct 2020 04:11
Profile
Writer

Joined: 17 Aug 2021 01:10
Posts: 12
Reply with quote
Всем добра.
С интересом прочитал эту тему, но мало что понял, потому как в теории не силен. Но хотелось бы задать несколько вопросов по железу, так как есть у меня плата для Гигатрона, и вот думаю, стоит ли браться за сборку. Был бы признателен получить ответ от квалифицированных специалистов.

1. Микросхемы.
В оригинале и в продаваемом наборе использована HCT-серия. Также авторы собрали один экземпляр на советской 555-ой серии, ну и все работает. Однако у меня нет полного комплекта микросхем из одной серии, а получается набрать солянку из HC, HCT, LS, ALS, AC. Заведется ли такой набор? В Спектруме (собирал Harlequin) такой вариант работает, а как здесь? Не будет ли проблем?

2. SRAM.
У авторов 62256 с временем доступа 55 нс. У меня есть только 62C256 45 нс. Подойдет ли такая замена?

3. ROM.
Подойдет ST M27C1024-10F1 с досупом 35 нс?

4. Проблема найти кварц на 6.25 МГц. Нельзя ли собрать, к примеру, генератор на 25 МГц и использовать делитель на 4?

Заранее благодарю за ответ.


17 Aug 2021 02:23
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
1N4148 wrote:
... есть у меня плата для Гигатрона, и вот думаю, стоит ли браться за сборку.
Безусловно, браться за сборку стОит! Конструкция очень интересная, заодно и опыта наберётесь!
Только не делайте популярную глупость: "если есть плата, я воткнул все микросхемы... а оно и не работает!" :roll:
Собирайте последовательно, поблочно, каждый раз проверяя работоспособность по Proteus-модели.
1N4148 wrote:
авторы собрали один экземпляр на советской 555-ой серии, ну и все работает. Однако у меня нет полного комплекта микросхем из одной серии, а получается набрать солянку из HC, HCT, LS, ALS, AC. Заведется ли такой набор?
Смешивать серии обычно не рекомендуется, но здесь я не вижу ничего слишком критичного.
Железных гарантий дать не могу, но советую начать сборку как я объяснил выше.
Естественно, неплохо иметь осциллограф для наладки, вслепую может и не получиться... :-?

1N4148 wrote:
У авторов 62256 с временем доступа 55 нс. У меня есть только 62C256 45 нс. Подойдет ли такая замена?
Подойдёт.

1N4148 wrote:
Подойдет ST M27C1024-10F1 с досупом 35 нс?
Подойдёт.

1N4148 wrote:
Проблема найти кварц на 6.25 МГц. Нельзя ли собрать, к примеру, генератор на 25 МГц и использовать делитель на 4?
Можно!

1N4148 wrote:
Заранее благодарю за ответ.
Не стОит благодарности!... :wink:
Как шутит один мой близкий друг:"Лучше маленький рубль, чем большое спасибо!" :lol:

_________________
iLavr


18 Aug 2021 06:02
Profile
Writer

Joined: 17 Aug 2021 01:10
Posts: 12
Reply with quote
Lavr wrote:
Только не делайте популярную глупость: "если есть плата, я воткнул все микросхемы... а оно и не работает!"
Постараюсь не делать. Как показывает опыт, собрать конструкцию это лишь половина дела, или даже меньшая ее часть. На запуск и отладку часто уходит больше времени.

Lavr wrote:
Смешивать серии обычно не рекомендуется, но здесь я не вижу ничего слишком критичного.
Естественно, неплохо иметь осциллограф для наладки, вслепую может и не получиться... :-?
Я так понимаю, что при смешивании серий нарушается Божественная Гармония, и конструкция начинает стремиться к Хаосу.
Однако заметил, что зарубежные коллеги часто вообще не заморачиваются по этому поводу и ставят всё, что под руку попадется. Что ж, поступлю так же.
Осциллограф есть, но аналоговый. Теплый ламповый.

Lavr wrote:
1N4148 wrote:
Проблема найти кварц на 6.25 МГц. Нельзя ли собрать, к примеру, генератор на 25 МГц и использовать делитель на 4?
Можно!
Кварц вроде нашел, должен отписаться поставщик. Надеюсь обойтись без делителя.

Так-то вроде все найду для сборки, но неожиданно всплыла еще одна проблема.
Когда собирал Спектрум, то пришлось еще и программатор для прошивки УФ-ПЗУ собрать, Willem. Я что-то был уверен, что 27С1024 он шьет, а оказалось - нет, не шьет. Вернее, может, но только с 16-бит адаптером. Так что теперь и адаптер, видимо, придется собирать :)
Так как рубль я передать не могу, то примите все-таки мою благодарность за развернутый ответ. Гран мерси.


18 Aug 2021 07:02
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
1N4148 wrote:
Я так понимаю, что при смешивании серий нарушается Божественная Гармония, и конструкция начинает стремиться к Хаосу.
Божественная Гармония в этом случае совершенно не при чем.
У разных серий разные задержки распространения, нагрузочные способности, а порой и логические уровни.
Поэтому могут неожиданно вылезти иголки, случиться непредвиденные гонки и т.п.
1N4148 wrote:
Однако заметил, что зарубежные коллеги часто вообще не заморачиваются по этому поводу и ставят всё, что под руку попадется.
Вот тут как раз всё с точностью до наоборот.
Все знают, что смешивать серии не есть хорошо, но это не божественный закон, просто когда ставишь другую серию, следует подумать, к чему это может привести.
Gigatron, как и другие любительские компьютеры не полностью синхронный, и иголки в нём точно могут случиться, даже в Proteus-модели это видно.
Другое дело, к чему это приведёт? Может безболезненно обойтись, а может проблему создать.

1N4148 wrote:
Осциллограф есть, но аналоговый. Теплый ламповый.
Да "аналоговый" - это совсем не порок! :wink: Я сам больше люблю аналоговые.
Главное, чтобы полоса была хотя бы 10 МГц, ну и не забудьте, что в цифровых схемах на таких частотах желательно щупать щупом 1:10.

_________________
iLavr


18 Aug 2021 11:26
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
1N4148 wrote:
Lavr wrote:
Главное, чтобы полоса была хотя бы 10 МГц, ну и не забудьте, что в цифровых схемах на таких частотах желательно щупать щупом 1:10.

Полоса 40 МГц, делитель 1:10 тоже есть.
Вообще нарисовывается картина, что все есть, кроме прошитой ПЗУ.
Программатор у меня Willem версии 3m, совместим с 3.5 ...

Программатор Willem v.3m выделил в отдельный топик.

_________________
iLavr


17 Sep 2021 05:07
Profile
Writer

Joined: 17 Aug 2021 01:10
Posts: 12
Reply with quote
Подскажите, а почему авторы выбрали SRAM (LY62256PL-55LLI) с временем доступа именно 55 нс? В DIP-корпусах такие труднодоступны, может, можно заменить на 70 нс?


13 Dec 2021 02:44
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
1N4148 wrote:
Подскажите, а почему авторы выбрали SRAM (LY62256PL-55LLI) с временем доступа именно 55 нс? В DIP-корпусах такие труднодоступны,

Я так думаю, что авторы выбрали SRAM (LY62256PL-55LLI) с временем доступа именно 55 нс в DIP-корпусе,
потому как для них эти SRAM труднодоступными не были.
Attachment:
гиг.PNG
гиг.PNG [ 492.07 KiB | Viewed 8187 times ]

Тем более, что авторы продавали наборы для сборки Gigatron-а, и очевидно не испытывали трудностей со SRAM.

1N4148 wrote:
может, можно заменить на 70 нс?
В этом очень легко убедиться самому! Берёте модель Gigatron-а из этого топика, в свойствах SRAM выставляете
параметр 70 нс, и смотрите - будет модель работать, или нет... :wink:

_________________
iLavr


13 Dec 2021 04:56
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 94 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.