SjASMPlus от z00m

[Ped7g]

Видео работы известных DMA-demo c zxnDMA на NEXT есть в сети??

I don't know. I think I was trying it while testing my ZEsarUX emulator fork, and the dma1demo did work correctly only in zilog mode. In zxnDMA it did look initially almost correct, but it got damaged over time. I still haven't unbox my real Next, because I'm in the process of moving my flat, and also staying not at home for few weeks, so Next is still waiting for me.

У меня первое демо с небольшими артефактами работает, и просмотр multitech-color-graphics лучше работает в режиме zxnDMA , чем в режиме zDMA.

Well, the difference between zilog and zxnDMA mode on Next are very small, the major difference is the N+1 vs N length of transfer. On Next even Zilog DMA mode is lot more relaxed, allowing for shorter and simpler init than real Zilog chip.

So I'm a bit confused why zxnDMA would work better for legacy SW designed for Zilog DMA, maybe you are running them on the wrong display mode: zx48 vs zx128 vs zx128+3 (= native Next timing) vs Pentagon ("soviet" timing), all of these have slightly different timing of display signal, so if you pick timing which is incorrect for the demo, and incorrect DMA mode, maybe by accident they cancel out, and you get nice multicolors then...

I'm not familiar with the SW you are trying, so I don't know which HW you should select.

For me as SW author the important fact is, that both DMA modes work as described and I can choose which mode I want to use (in my recent "big picture scroll example" https://github.com/ped7g/ZXSpectrumN...r/Layer2BigPic I'm using the zxnDMA mode, because I have already in B the length of transfer, which is always 256*n, so it's simpler for me to load the B directly into dma.length, then having to do "-1" for Zilog mode).

[Advertiser]

[zebest]

I still haven't unbox my real Next, because I'm in the process of moving my flat, and also staying not at home for few weeks, so Next is still waiting for me.

Для DMA не так много SW. И все оно собрано у Velesoft-a :
https://velesoft.speccy.cz/data-gear.htm
Интересует, как будет выглядеть на настоящем NEXT.
В эмуляторе у Цезаря действительно работает отвратительно.
Подождем. Жить еще долго.

[NEO SPECTRUMAN]

Ped7g, так же еще не хватает возможности дописывать один файл при помощи SAVETRD
по типу как это сейчас с defarray+


ну или нужна возможность
копировать блоки памяти
чтоб можно было собрать все нужное
и записать одним блоком

slot 0 : page 100
slot 1 : page 101
slot 2 : page 102
slot 3 : page 103

copy $0000,1,$0000,$200
copy $0000,3,$0200,$400 ;copy from $0000 page 3 to $0200 current memory map $400 bytes
copy $0000,3,$4000,$4000

SAVETRD "1.trd","2.C",$0000,$4600

[Dart Alver]

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

Плюсую, это сильно бы облегчило жизнь для сборки монолоэдеров.
Хотя по мне проще было бы чтото типа:

ADDTOENDTRD "disk.trd", start_address, length_in_bytes

чтобы к последнему файлу в образе диска добавлялся новый блок (в конец файла начиная со следующего сектора диска) и соответственно увеличивался рамер файла в секторах (остальные параметры не менялись), а если количество добавленных секторов зашкалило за 255, или за размер диска вылезли, или в образе вообще файлов нет, то ругалась ошибками ))

А ещё было бы неплохо добавить в SAVETRD возможность записывать в каталоге TRD-образа изменённые стартовый адрес и длину в байтах, не трогая длину в секторах. Для коррекции BASIC - программ может быть полезно.
Например добавив ещё 2 необязательных параметра:

SAVETRD "disk.trd","boot.B", start_address , length {, catalogue_start_adress} {, catalogue_bytes_length}

Вообще последнее конечно можно и через LUA откорректировать, но всёже

[NEO SPECTRUMAN]

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

я для этого и прошу
я то гружу как monoloader
но файлы так и валяются друг за другом

[Ped7g]

I don't feel confident enough with TRD file format (which is mostly NOT covered by tests in current sjasmplus) for such big changes, so I'm not planning to touch this for v1.15.0, but maybe later in future.

I.e. if you want to accelerate this (still unlikely to hit 1.15.0, but maybe we can do it for 1.16.0), you are welcome to produce the patches, so I can review some particular implementation.

If you want to make it super friendly for me (sadly I'm lately doing 95% of sjasmplus contribution, but there *are* other contributors, so some of them may pick up your ideas and help you too, if you make it more visible, i.e. issue in english on github or pull requests with code), then please try to follow this order:

- add tests for current TRD (HOB belongs to this too?) code, so the code-coverage in tests is near 100% like it is with SAVETAP/SAVEBIN/... (if you will check the coverage reports, you will easily see which use-cases are covered by tests, and which one I keep ignoring as I don't care about those too much)

This is quite essential step to keep the quality of the future releases at "at least as good as previous version, or the change was intentional and documented". JFYI writing tests for directives like SAVE is not trivial, unfortunately it requires some understanding for how I designed the test runner and how I'm hacking it to check this kind of directives. You can learn it all from studying the current source + tests, but it's not beginner friendly, sorry (there was no time to write some nice docs or tutorial, plus nobody ever shown interested to write sjasmplus tests).

- add pull request for some reasonably small change with tests for the new behaviour included

It will be more difficult for me to ignore actual code provided (than to just remember that I have seen something on zx-pk forum, but pushing it for later in mind, because I have always something more important or more fun to do), so this would greatly increase the chance of getting the feature into mainline.

(also if you are already familiar with sjasmplus sources, build process, and testing, nobody can stop you for using your own fork with the proposed changes ahead of z00m's branch, actually reports from some experimental real-world usage will further help the cause, as you could then confirm the changes work well and files produced work on actual machine ... to avoid similar funny situations like the "mul" opcode for Z800 being in sjasmplus for a decade+ wrong, or the INCLUDETRD (or was it HOB?) with the "offset" argument being used wrongly ... probably also for decade+).

Meanwhile **I** really want to focus on v1.15.0, which for me means only to remove the alternative code for MSVS builds, to have binaries built by VS coming from the same source as GCC/CLANG builds, so I can enable the test-suite on windows builds fully, all the other changes are IMHO ready to be released and hopefully the release will be finished within week or two (I was hoping to release it already 2 months back, sigh )

edit: this is like frankly telling you, that I'm at this moment in time not interested to work on these requests. I'm not against them, just doesn't have enough priority for me (and I'm quite busy with other projects), so I don't want to keep you hanging here and waiting for next release hopefully. Rather telling you upfront I'm not working on these now. But they look good as possible future improvement. The overall QA work on TRD directives would be nice, as this area of sjasmplus is currently sub-par compared to the rest of the assembler.

[Bedazzle]

Интересует, как будет выглядеть на настоящем NEXT.

Что проверить нужно?

[zebest]

Что проверить нужно?

https://velesoft.speccy.cz/data-gear.htm
Желательно все, ну хотя бы как выглядят картинки в обоих режимах (тЕ что там на картинках, насколько точно и сколько артефактов), в первой демо у меня артефакты в буквах, думаю что тайминги не сходятся, в третьей демо есть ли "поддергивание" бегущего текста и насколько частое, в DNA Demo - там тоже картинка не вполне идеальная )
Думаю DNA вполне показательно было бы видео Чтобы судить о точности эмууляции.
Остальных хватит и пару картинок для оценки.

[Bedazzle]

https://velesoft.speccy.cz/data-gear.htm
Желательно все, ну хотя бы как выглядят картинки в обоих режимах (тЕ что там на картинках, насколько точно и сколько артефактов), в первой демо у меня артефакты в буквах, думаю что тайминги не сходятся, в третьей демо есть ли "поддергивание" бегущего текста и насколько частое, в DNA Demo - там тоже картинка не вполне идеальная )
Думаю DNA вполне показательно было бы видео Чтобы судить о точности эмууляции.
Остальных хватит и пару картинок для оценки.

По картинкам как-то совсем хреново.
Ч/б разваливаются, показываются как статическая картинка спека без атрибутов.

Цветные - нормально отображаются, но как просто ч/б картинки.

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

У некста есть в конфиге переключение DMA - Z80 или ZXN.
Далее при запуске тапки (пробовал 3.5/7/14/28 мгц) выскакивает выбор режимов
128K / USR0 / 48K / Pentagon / Next (+3 mode)

и когда стартует сама программа, выбор порта, на котором DMA
port 107 (Data-gear) или port 11 (MB02+)

- - - Добавлено - - -

на 107 порту
в ч/б демках стало показывать рандомные атрибуты,
в цветных тоже атрибуты появились, но это явно не мультиколоры, а обычные спековские экраны

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

[zebest]

в последнем разпоследнем релизе два режима DMA, на 107 порту - zxnDMA висит, и на 11 порту - как бы прежний z80 DMA. По идее демки должны работать в обеих вариантах, с некоторой разницей - но работать. Так что пробовать по два раза запускать и выбирать порты по очереди. желательно в режиме zx128.
возможно DMA отключено глобально?
Если релиз ядра не самый крайний - тогда вЫбери в конфиге DMA Z80 и пробуй еще раз по обеим портам.