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.
В эмуляторе у Цезаря действительно работает отвратительно.
Подождем. Жить еще долго.

[Bedazzle]

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

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

[zebest]

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

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

[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.

[zebest]

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

[Ped7g]

Yes, since core 3.1.5 (Next OS "distro" 1.3.2) the port $0B is only ZilogDMA mode, port $6B is only zxnDMA mode. The previously used config bit in NextReg 06 is now used for beeper configuration, not related to DMA any more.

The SW from Velesoft page should NOT work well with $6B (zxnDMA), there's not much point to even try that, the $0B port has better chance.

But there is one more issue with SW from Velesoft page. There's lot of CZ/SK community production, done with the UA880d DMA chip (East Germany clone of Zilog DMA chip), which does *NOT* react to the "WR3.enable" bit.

And by some unfortunate coincidence, lot of the early DMA SW does set this bit to "1" half-way into the init, there was even article in Czech paper magazine describing how to program DMA on ZX, which did contain the same bug writing to WR3.enable early.

But the original Zilog DMA and some other clones (*and* the FPGA implementation in ZX Next) do react to the WR3.enable, and will start the transfer (as if DMA_ENABLE $87 command was sent to WR6).

This issue was identified and known by the cz/sk community few years later after the first versions, and later versions of MB-02 disk system BIOS were patched to work correctly even with original Zilog chips, also some demos were patched, but I'm not sure if somebody did review all the SW on Velesoft page and mark which contain the WR3 bug and which is compatible with Zilog chip.

If you have SW which does work with original Zilog chip, and does use port $0B, and you did select the correct video timing of your Next (of course you need VGA mode, not HDMI) to simulate zx48/128/+3 machine, then I would expect most of the old demos to work correctly, the 48/128/+3 timings of Next are quite accurate AFAIK (demos doing multicolors like Shock work usually pixel perfect, there were few pieces like muco1k from Busy which were not completely correct on Next the last time I have seen it (back in early 2018), but it was not completely clear if muco1k is correct on real HW, as Busy did use emulator to tune the timing ... I'm not sure if somebody managed to do proper test of it, real HW vs Next HW and after all the timing fixes were applied to Next)

Actually, looking at (incomplete) changelog of Next core ( https://gitlab.com/SpectrumNext/ZX_S...t/changelog.md ) there was small fix to timing even in core3.1.0, so I guess nobody did run side by side HW vs Next for these demos which are so critical on the timing accuracy.

So any precise input from people who can do the tests is welcome, but make sure you fully understand the complexity of Next setup and that you are testing in the correct mode and correct thing (with the extra bonus of some intros like muco1k containing machine-detection code, so it's better to avoid that and load the correct version explicitly, as the detection code may fail to pick the correct model too.

In ideal world it should be on Next (running with VGA mode at 50Hz) as easy as to select your video timing (48 / 128,+2 / +2A,+2B,+3 / Pentagon) and ROMs (this is what the TAP and SNA loader does, with TAP loader displaying menu to select the machine configuration by user, SNA reads snapshot type and modifies the HW config automatically based on the type), and just run the SW and all should work.

If it does not work correctly, and you can identify what is failing, please report it to the Next team, it's important piece of information. But it's also very tricky to find the true reason where is the problem, as there are many details contributing to the final result, as you can see from this post (it was supposed to be short 2-3 sentence post, and it's whole page instead, argh).

- - - Updated - - -

So, I downloaded the dma-demo-level_1.zip from velesoft page, added debug printf into ZESERUse (fork of ZEsarUX) to print every byte going to DMA port and this is the init sequence:

($0B) = $C3 RESET
($0B) = $C7 RESET port A
($0B) = $CB RESET port B
($0B) = $7D WR0 + port A adr + length, A->B, transfer
($0B) = $21 A.adr = 0x4021
($0B) = $40
($0B) = $BE length = 0x07BE
($0B) = $07
($0B) = $14 WR1, A++, memoryA
($0B) = $10 WR2, B++, memoryB
($0B) = $C0 WR3, enable=1
DMA Transfer with mode 0 (single byte) requested - ignored
($0B) = $AD
($0B) = $20
($0B) = $40
($0B) = $82
($0B) = $CF
($0B) = $B3
($0B) = $87
....

I added comments from beginning to the WR3 write, which wrongly enables the transfer (prematurely, before the DMA_LOAD command). So the demo works only on the UA880d cloned chip, which ignores this WR3 write.

If you are bored, you can try to disassemble the demo and find the init sequences and turn $C0 into $80 in each of them (writes all-zeroes to WR3, which is actually important on real Zilog DMA, because it somehow affects timing without the write to WR3 - it's still a bit mystery why/how, as the other bits are related to interrupts/etc which is not used on MB-02 + Zilog DMA, but by testing with real HW we did find that writing explicit zero to WR3 somehow makes the machine timings more stable).

But at this moment, Next with it's Zilog DMA emulation, can't run the SW which has the WR3.enable bug correctly, there's no such option on Next.