TRDOS 6.11P

[hood]

Товарисчи,

Начал разработку сабжа.
Первоначальная цель разработки - хочется TRDOS для ZXM Phoenix, с RAMдиском и автозагрузкой с HDD/CD.
Вторичная цель - вспомнить все

Что есть на данный момент:
09.12.2009 (версия тут)

• версия 6.10e портирована под модель памяти PHOENIX
• добавлен автодетект размера памяти и соответственно размера RD
  
  • при объеме памяти 2Мб - Ram disk 1Mb, расположен в верхних 64 страницах
  • при объеме памяти 1Мб - Ram disk 768K, расположен в верхних 48 страницах
  • ячейка памяти #5CB0 содержит маску возможных страниц памяти (#7f для 2мб, #3f для 1мб ит.п.)

Полученные пожелания:

• работа со вторым мегабайтом через D6 #7ffd
• версия с 768К диском под SCORPION 1024, PENTAGON 1024, ATM 1 1024, KAY 1024, PROFI 1024

Если у кого есть желание потестировать, поделиться идеями - welcome!

PS: Unreal c поддержкой PHOENIXa на базе 0.37.3 можно взять тут
или на базе 0.37.0 с подключенным образом FAT32 винта тут

---------- Post added at 11:12 ---------- Previous post was at 10:58 ----------

И сразу вопрос - Есть ли какой нибудь стандарт спектрумовский по автозагрузке с FAT32 винта и с CD? или за стандарт можно считать глюк?

Здравствуйте, попитаюс по рускому.

С VELESOTом мы тепер занимаемся портировать ваше рамдисковые ТРДОСы на наше сыстемы. Мы хочем загрузить ТРД диск из нашего система. Мы запиталы сделать только ЛДИР ТРД имаге до банк памяти, но ТРДОС не хочет работать. Знеате сказать кде проблема? Можно нам нужно тоже какое то контрольные XOR счëты сделать?

Cпасибо, как можно ответить по английcкому.

HOOD

[Advertiser]

[alsp]

Знеате сказать кде проблема? Можно нам нужно тоже какое то контрольные XOR счëты сделать?

In my opinion - best way to move TRD image to the RAM drive - make per sector copy - i.e. read each sector from TRD image and after that write it to the RAM drive using usual TRDOS function. In this case you will be abstracted from internal specific of RAM drive... and all functioanlity should work correctly. As I know WDC software use similar algoritm when make unTRD operation...

---------- Post added at 12:30 ---------- Previous post was at 12:24 ----------

alsp, в перспективных компах на ПЛИС, ПЗУ размещают в виде образа в ОЗУ (обычно отводят под это 512к), поэтому чтоб не переделывать потом, желательно учесть сразу возможность того, что объём ОЗУ в компе кратен 512кб а не 1Мб.

у меня при определении потенциального объема диска процедурка считает разные страницы памяти от 0 до... потом записывает маску страниц по этому адресу... т.е. для 512K там по идее будет #1f , для 256 - #0f - поэтому по идее кратность тут не особо важна...
Другой вопрос - надо бы учесть карты памяти - т.е. ввести в алгоритмы карты распределения RD - чтобы можно было задавать зарезервированные страницы...

[hood]

In my opinion - best way to move TRD image to the RAM drive - make per sector copy - i.e. read each sector from TRD image and after that write it to the RAM drive using usual TRDOS function. In this case you will be abstracted from internal specific of RAM drive... and all functioanlity should work correctly. As I know WDC software use similar algoritm when make unTRD operation...

Thanks a lot for the answer. Velesoft told me, he is already in contact with you.

I just wanted to avoid completely programming in TRDOS, because this is not my native system. So, you really do not know what extra work must be done (XOR checksums, etc.) if we want to import TRD image into RAM banks and at the same time avoid TRDOS programming?

I thought just ldirs would be fine, but this is not enough, TRDOS freezes.

Thank you

Hood

[alsp]

So, you really do not know what extra work must be done (XOR checksums, etc.)

The main problem in this scope is internal structure and algorithms for RD - for example in my variant Ram disk growing up - i.e. zero track placed in the latest bank but in one bank sectors growing down. And in some other implementation of RD - it can be absolutely different. (I plan to add memory map feature that will describe witch memory banks can be used for RD). So if you want to support all RD variants you should investigate algorithm that map track and sectors numbers to the memory address for every one...

---------- Post added at 13:04 ---------- Previous post was at 12:57 ----------

А кстати, возможность считывать значения портов #1FFD, #7FFD, #EFF7 тебе поможет в работе?

это может унифицировать часть алгоритмов для разных платформ и ускорить работу алгоритмов работы с RD. Потому как на данный момент текущая страница вычисляется прогоном цикла по всем страницам от 0 до текущей... (или от последней до текущей...) и, таким образом, восстанавливаются значения портов для возврата в текущую страницу после работы с RD.