New product: MNT ZZ9000

[IvanEBC]

Well at least what i'm seeing is relatively normal then.
I just need to go through 2 boots to see my pretty Workbench
3 if i want a butt load of fast ram.
First world problems i guess haha!

[mousehouse]

I started noticing this after I added the BFG9060 to my 3000. Before I did it was probably so slow, the ZZ9000 had plenty of time to get everything initialised. With the fast 060 I need an additional reboot for the memory. I just loaded the no-mem firmware version as I do not need 256MB of slow memory anyway... problem solved!

[Jope]

I used to run mine with a kickflash os4 which did the necessary reboot for me, so it was always fully ready when the OS was loading for real. :-)

But these days I run the no-mem firmware, I really don't need the slow RAM on top of what is on my CPU card.

[eXeler0]

Originally Posted by mousehouse

I started noticing this after I added the BFG9060 to my 3000. Before I did it was probably so slow, the ZZ9000 had plenty of time to get everything initialised. With the fast 060 I need an additional reboot for the memory. I just loaded the no-mem firmware version as I do not need 256MB of slow memory anyway... problem solved!

As soon as my long awaited ZZ9000 arrives Ill be in this situation, but I honestly cant think of a use case where Id need the RAM from the ZZ9k on top of what I already have on the BFG9060.

[Etze]

Originally Posted by mousehouse

I started noticing this after I added the BFG9060 to my 3000. Before I did it was probably so slow, the ZZ9000 had plenty of time to get everything initialised. With the fast 060 I need an additional reboot for the memory. I just loaded the no-mem firmware version as I do not need 256MB of slow memory anyway... problem solved!

Matze provided a flash-update for the bfg with a small delay just for the ZZ9000. Works like a charm! https://www.a1k.org/forum/index.php?...8#post-1625687

I don't need more than 128 MB (+16 MB on the Motherboard +2 MB Chip), too. But it "feels" better with more RAM.

[eXeler0]

Originally Posted by Etze

Matze provided a flash-update for the bfg with a small delay just for the ZZ9000. Works like a charm! https://www.a1k.org/forum/index.php?...8#post-1625687

I don't need more than 128 MB (+16 MB on the Motherboard +2 MB Chip), too. But it "feels" better with more RAM.

I was thinking about this. I'm guessing the RAM on thje BFG would be much faster than the motherboard RAM so, could you actually benefit (speed-wise) by removing Motherbord RAM?
Also, did you add "MuFastROM PROTECT ON" to startup?

[alexh]

Originally Posted by eXeler0

I'm guessing the RAM on the BFG would be much faster than the motherboard RAM

Correct.

Originally Posted by eXeler0

so, could you actually benefit (speed-wise) by removing Motherbord RAM?

No. AmigaOS implements RAM priority on address ranges. Meaning as long as there is accelerator FAST RAM available it will use those addresses over addresses in motherboard FAST RAM.

It is my understanding that you can change the RAM priority of address ranges so you could test this. But I wouldn't bother.

[thebajaguy]

Running into a problem with the latest firmware - 1.12.1 on an A2000.

When I power up, or Ctrl-A-A, I get an LED flash several times, and the system resets and repeats the LED behavior. 68000 CPU, no other cards. I've tried OS 3.1.4, and 3.2.1 ROMs. I have tested the 2MB and 4MB boot.bin images. I've reformatted the SD card with FAT32. I've put cards in front of the ZZ9900, and tested in slots further out - no change in the problem.

The Z2 firmwares work correctly in my A4000T/060 (alongside a second ZZ9900 in Z3 form - the latter Z3 card is mine, and the former is a card for someone else's system I'm updating). The A2000 I'm testing with is my test mule system, but is the same in the owner's A2000 system. Both are Rev 6.2 w/2MB ChipRAM.

If I go back to firmware 1.8, Z2 4MB, it AutoConfigs correctly in the 68000 machines.

DiagROM (last Oct 2022 Daily Build) behavior note: On A2000 power on, the DiagROM acts very slow on start, and ultimately reports no ChipRAM. Ctrl-A-A, it then behaves normally and finds proper ChipRAM. Something is holding the bus up early? Also, a bug in manual AutoConfig in DiagROM (reported today, option 8, then 2) tries to place the 2/4MB Z2 RTG memory space at a Z3 $4000.0000 address. It does this with a GVP Spectrum 28/24 (with or without forced Z2 set) and a Golden Gate bridgecard also, so attributed to DiagROM, and not ZZ9900 behavior. Bug was reported to John Hertel.

The A2000 system will have an accelerator (P5 68060/50) when all testing and updating is done, but I need bare-bones working behavior first.

[thebajaguy]

(This has been edited - consider it informational only)

BFG memory will be the fastest. The other memory in the system is thankfully naturally ordered in fastest to slowest, and no adjustment is normally needed to change the order.

With regards to motherboard RAMSEY memory vs Z3 Expansion memory, like ZZ9900's (on a best-case Buster-11 situation). Neither motherboard memory nor Z3 expansion card memory is particularly stellar in speed, but RAMSEY motherboard memory has a minor advantage as there is fewer bus synchronization steps occurring, particularly for accelerator cards that are Async to motherboard clocking.

Your accelerator card's onboard memory will most likely support burst access to it, or it's very fast and tuned to the CPU bus, so Copyback mode for that range is normally ideal. This setting applies to the BFG and most other cards with onboard RAM.

Focusing on remaining motherboard/expansion bus (ZZ9900) performance, the proof of making adjustments to the slower 32-bit memory options is below:

Example system 60MHz 68060/A4000T/Accelerator which has own on-card memory, but that RAM is not relevant to the performance topic.

RAMSEY-07 Motherboard Memory (16MB):
nocache - 6.1/12.2 reads, 8.1/16.2 writes.
copyback - 14.8/16.2 reads, 9.2/9.3 writes.
writethrough - 14.9/16.2 reads, 8.1/16.2 writes.

ZZ9900 (256MB) memory in above 68060 system:
nocache - 3.8/7.6 reads, 5.2/10.4 writes.
copyback - 8.6/9.0 reads, 5.2/5.2 writes.
writethrough - 8.6/9.0 reads, 5.2/10.4 writes.


An A3000 16MB RAMSEY-04 motherboard DRAM, and an A3660, w/50MHz 68060:

nocache - 3.8/7.5 reads, 4.8/7.8/10.5 writes*.
copyback - 10.3/9.0 reads, 6.1/6.1 writes.
writethrough - 10.3/10.9 reads, 6.1/12.3 writes.
(has the 2 wait state removal GALs enhancement on the CPU card - A3660 included to show cache mode behavior only)

Tools: MuSetCacheMode/MuScan for cache mode setting/verify, bustest (mlelstv) for speed testing (used the addr parameter to target memory ranges).

Bustest Notes: First value is the W. Second value is the L and M values combined as all were same or within ~0.2, except in (*) noted case.

Benchmark Disclaimer: Caches and burst access work in favor of sequential data access. Random data hurts performance, and actually hurts Copyback Mode use the most. It is even more so if the memory is not running at optimal speeds of the CPU's main bus (optimal = on-accelerator memory).

I actually recommend to most to disable (with MuLibs Tools/config file) the 68040/68060 copyback mode on the slower A3000/A4000 RAMSEY/Z3 Expansion card RAM when they have faster on-accelerator memory present - picking Writethrough mode instead. Why? This RAM will be used later, and probably for small random pieces when the better faster memory is consumed. Then the Copyback mode may have to do a 4x long-word write flush of an unwritten-to-RAM cache line against slower memory before the CPU is permitted to continue on and allocate/cache a new 4x longword (LW) access (write) into copyback cache, and/or it may have to then read a 4x LW line from that slower memory to satisfy a read access need. Writethrough mode doesn't have to do the pre-flush, so the overall penalty hit is much less in less than optimal random-access situations. One should still run other benchmark tests (like AIBB) to see where you gain and where you lose performance (and be sure you are running against the slower memory zone). There will be tradeoffs. Every system will be different.

Due to the above, and the extra penalty of double 16-bit accesses, I recommend no caching of any older Z2 16-bit memory spaces with a 68040/68060. MuLibs has a sub-section in it's notes now regarding this after some extensive testing found it could even lock up the system (multiple accelerator cards were tested, in A2000/3000/4000's). As the 16-bit memory, when present, is last to be used, few encounter issues unless very low on RAM.

Additional comments:

The 68030 doesn't have Copyback mode, and runs more closely to the 68040/060 Writethrough mode (for the most part). It's bus access design is also different. It has no prefetch pipelines to stall when accesses/caching go against the much slower memory busses being one benefit. Therefore, much of this won't apply to a 68030 system.

Most 68040/060 accelerators, when they access the motherboard/expansion spaces, convert their fast CPU-burst access into 4x single 32-bit word accesses, which is why they are much slower accesses than on-accelerator memory.

There are some rare accelerator card designs that can take advantage of A3000's SCRAM on the motherboard (like the 68030 can, at times). In these cases, allowing Copyback may behave better, but you have to test and confirm. The A4000 only has DRAM.

[alexh]

Originally Posted by thebajaguy

Responding to the ZZ9900 Z3 expansion memory vs motherboard memory discussion - alexh is incorrect

Which post is this in reference to? There are no posts from me in this thread about Z3 vs motherboard RAM.

[thebajaguy]

Originally Posted by alexh

Which post is this in reference to? There are no posts from me in this thread about Z3 vs motherboard RAM.

You are correct. I misread your post - BFG memory would be fastest.

Please take the post I made above as an informational on best setting up of the slower memory ranges. I will edit it to reflect this, too.

[eXeler0]

Delete dbl post

[eXeler0]

Seems my ZZ9000 finally arrived and is waiting to be picked up. I have the latest P96 driver and my BFG 9060 should have the latest firmware to fix boot time issues. I intend to use USB for file exchange, Ethernet -most likely.
Anything else I should be aware of regarding the ZZ9k?
Anything that utilizes the ARM chips?

[gdonner]

Originally Posted by eXeler0

[snip] ... Anything that utilizes the ARM chips?

AFAIK (at the time of writing), only AXMP3 (directly) and AmigaAMP3 (via MHI driver), used for offloading playback of MP3 files with minimal Amiga resources.

However, Lukas has at least(?) a couple of ideas in mind for the near future; namely:

• Explore TLS acceleration
• Implement JPEG decoding operation

[source: https://source.mnt.re/amiga/zz9000-firmware/-/issues]

I'd like to think that the ARM-based JPEG decoding operation could somehow also potentially include all image datatypes, but that's purely ignorant conjecture on my part.

[levellord]

@eXeler0
To exchange files, it will be easier to use RNOXfer over lan than USB, just because USB stick needs to be present during the boot. RNOXfer works great and I can transfer files between my AmigaNG, classic system and NAS with no hustle, everything is done withing seconds or minutes, depends on the file size. But this is entirely up to you and your preferred method. If you don't have it, you will need Roadshow.

@gdonnor
lol, I would also like to see more image datatypes and even more, like video decoding which is probably just an hollow hope.

[qz3fwd]

I wonder if the arm cores include a GPU core which could be used for hardware video decode? Wouldn’t it be cool seeing an Amiga decode 1080p or higher h264/265 videos! One can only dream.

[eXeler0]

Took a few tries and P96 /driver re-installs for some reason to get it working but I’m still not sure how the scandoubler is supposed to work. Right now I have HDMI to one monitor and RgB out to another (15kHz) capable monitor.
Ran a demo and the HDMI display went crazy. Is RGB out scandoubled? (Ok, Ill try when I get home ;-)

[gdonner]

Originally Posted by levellord

@gdonner
lol, I would also like to see more image datatypes and even more, like video decoding which is probably just an hollow hope.

Not at all--at least for the WebM and VP9 formats, and the frame rate seems smooth:

https://twitter.com/mntmn/status/1247289783262609414

Of course, what resolution the video playback was at wasn't mentioned by Lukas, but even something small like 640x480 would still be better than nothing at all!

[gdonner]

Originally Posted by qz3fwd

I wonder if the arm cores include a GPU core which could be used for hardware video decode? Wouldn’t it be cool seeing an Amiga decode 1080p or higher h264/265 videos! One can only dream.

It would indeed, but GPU-based video playback at 1080p needs a lot more than just an ARM processor. NVIDIA's GeForce cards, even the smallest ones, need a heat sink or a fan to keep their GPU cool. AFAIK I don't think it's possible (or practical) to combine a GPU with an ARM processor. My understanding is that they're very different kinds of chips, requiring different treatment/programming, etc.

Still, the ZZ9000 will, in time, be giving us more than we have now.

[gdonner]

Originally Posted by thebajaguy

Running into a problem with the latest firmware - 1.12.1 on an A2000.

When I power up, or Ctrl-A-A, I get an LED flash several times, and the system resets and repeats the LED behavior. 68000 CPU, no other cards. I've tried OS 3.1.4, and 3.2.1 ROMs. I have tested the 2MB and 4MB boot.bin images. I've reformatted the SD card with FAT32. I've put cards in front of the ZZ9900, and tested in slots further out - no change in the problem.

The Z2 firmwares work correctly in my A4000T/060 (alongside a second ZZ9900 in Z3 form - the latter Z3 card is mine, and the former is a card for someone else's system I'm updating). The A2000 I'm testing with is my test mule system, but is the same in the owner's A2000 system. Both are Rev 6.2 w/2MB ChipRAM.

If I go back to firmware 1.8, Z2 4MB, it AutoConfigs correctly in the 68000 machines.

[snip]

There's definitely several large bugs lurking in the ZZ9000 firmware (existing even before 1.12.1) that I've noticed:

- A horizontally-split screen appears at times on my A3000 when simply trying to open a Hi-Res Laced screen.

- On occasion, when rebooting after a crash, the Workbench screen stays on-screen (frame buffer related?) for a good 5-8 seconds while the system is rebooting, until it finally clears and the system is close to completing boot up.

- I've also been getting a weird graphics bug (link below) in IBrowse when running it for the first time after a reboot. My system is then rather unstable afterwards. Not sure if it's IBrowse, ZZ9000, or P96, but it's persisted through multiple versions of all three. I'm using the latest version of P96, v3.3.2, and IBrowse 2.5.7a.

(Jump to 6 seconds in for the bug): https://www.gregdonner.org/transfer/...ssue_crash.mp4