Create a reproduce movie in FM77AV 4096 color mode.

[KKTamu]

Hello,

Following *Learning 4096-Color Graphics with FM77AV*, I’ve started a new challenge.

In a way, this might be an overly ambitious attempt.

Even if it’s just in slow motion, I’ll push the limits and see how far I can go!

Of course, I plan to eventually apply double speed playback....

[KKTamu]

**4096-Color Mode: Two Images, Repeated Rendering Test Results**

The purpose of this test is to check the speed and image quality of the system before creating a video.

To fix the error that occurred at 'viewtopic.php?p=200199348#p200199348', I modified the process so that the Teraterm->Python->96KB VRAM file to XM7 virtual FD while rendering.
MMR is not used.


### **Speed:**
The rendering speed is faster than expected.
**85min. / 15,019frames = 3.40 FPS**
Tested on: **AMD Ryzen 5 8540U w/ Radeon 740M Graphics 3.20 GHz**
XM7 is set to **"CPU Full Speed Mode"**, and the video shown below is played at actual speed.

### **Image Quality:**
There is noticeable flickering because the system writes 12 planes one by one, with all 200lines at once.
To achieve 30 FPS, the recorded footage needs to be speed up by approximately '9x', which may reduce the flickering effect.

I plan to proceed as is.

[KKTamu]

I finally managed to record one.

To make the most of the 4096 colors, I chose a colorful or live-action video instead of animation.
This is a McDonald's TV commercial from Spain.

The actual rendering speed is 1.66 2.08FPS, and this video is played at approximately 18x speed.

In sections where the subject moves quickly, flickering becomes more noticeable.

but, the images are so beautiful it's hard to believe they were taken from an 8-bit computer 40 years ago.



Next, we'll try to see how much flicker can be improved by using MMR.

[jimbobaby]

I finally managed to record one.

In sections where the subject moves quickly, flickering becomes more noticeable.

Next, we'll try to see how much flicker can be improved by using MMR.

I don't know. If you are drawing the 12 bitplanes one at a time for each frame, then the artifacts (chromatic aberration) related to that are surprisingly very minimal (i would expect LOTS more). In fact the only moment that is very noticeable is at fades, like that:

capture1.png (315.6 KiB) Visto 515 veces

The rest of the video is very subtle in that regard.

But what seems "worst" visually in many parts of the video (for me, at least) are moments like this:

capture2.png (298.42 KiB) Visto 515 veces

As if there could be problems with the dithering sometimes. That is what i think you see as motion artifacts, but it's not related to colour fringe/chromatic aberration (or at least i think so ).

I don't know if it's a problem with the quality of the original video (and now the compression of youtube on top of that), or if you see the same problems with the raw footage.

To avoid chromatic aberration i would draw line by line (or even better, byte by byte -8pixels-), to minimize the time needed for pixels to have it's "final" color and avoid "intermediate colors".

And by the way, just for curiosity, the video is mirrored (texts are flipped)

[KKTamu]

jimbobaby-san,

Thank you for your comment.

Indeed, in my own video, this part of the color transition is the most noticeable.
The cause is just as you suspected.

I believe the same cause applies when the subject moves relatively significantly.
Since I observe the same phenomenon in my video, I don’t think it’s due to YouTube’s streaming.

As you mentioned, rendering by dividing the image vertically seems to be the most effective approach.
However, before that, I will first test whether applying MMR has any effect.

The image has been intentionally mirrored.
Copyright reasons, etc.

[jimbobaby]

As you mentioned, rendering by dividing the image vertically seems to be the most effective approach.
However, before that, I will first test whether applying MMR has any effect.

As i see, MMR "by itself" is a commodity to allow using only MAIN for everything, and simplify code avoiding SUB synch and passing data through Common Area (too small).
But the downside it's that slows down MAIN from 1.8 to 1.6Mhz aproximatelly. But the code is much easier that way

The image has been intentionally mirrored.
Copyright reasons, etc.

Ok, i understand

[KKTamu]

### Execution Results of FD->MMR DIRECT WRITE 200Line



The drawing speed has improved by 11% compared to the previous attempt.
**30-sec movie.**
2.08 → 2.31 fps (+11%)
Recording time: 7.47 → 6.71 min

Visually, the flickering appeared to be about the same as before—if anything, it might have worsened slightly.
It seems I had overestimated the effect of MMR.

Thinking it through, the time-lag written from first plane to the twelfth out of the 12 planes does not change in relative terms.
Even if the overall processing speed improves, the proportion of this time-lag within the final, sped-up 1-frame duration (1/30 sec.) remains the same.

Next, I will try splitting the image vertically for rendering.

[jimbobaby]

Thinking it through, the time-lag written from first plane to the twelfth out of the 12 planes does not change in relative terms.
Even if the overall processing speed improves, the proportion of this time-lag within the final, sped-up 1-frame duration (1/30 sec.) remains the same.

Next, I will try splitting the image vertically for rendering.

You are right, i think you'll see better visuals rendering line by line

I see that you are using an even number of MMR "maps" (from $2000 to $6FFF), 5 4K "pages". That makes me think that that you already know about the "trap" at $7000 (floppy area) .

You can use "shadow ram" (aka RAM mode on $8000-$FFFF) for mappings if you don't use BIOS, or simply just map 1 or 2 "pages" and re-cycle them. MMR mappings are not expensive (well, except the cycles needed for the mapping instructions, of course ).

[KKTamu]

You can use "shadow ram" (aka RAM mode on $8000-$FFFF) for mappings if you don't use BIOS, or simply just map 1 or 2 "pages" and re-cycle them. MMR mappings are not expensive (well, except the cycles needed for the mapping instructions, of course ).

Jimbobaby-san,
Thank you for your comment.

I know how to use the Shadow RAM, but I want to use the BIOS for FD READ.
To be honest, I don’t have the technical skills to directly control the FDC and read from the FD.

When I made this video, I had to work within a very small free memory area, struggling to fit everything together.
There’s still a little space left, so I think I can manage somehow.

By the way, do you know why we have to map it with MMR in order to control bank switching for SUB I/O ($D430)?
Even though it’s only 4KB, it feels like a waste to put more pressure on the main memory.
Originally, I planned to map only VRAM with MMR and control SUB I/O through shared RAM, but no matter what I tried, I couldn’t switch the bank.
(Even when setting SUB RESTART and disabling MMR.)

[jimbobaby]

I know how to use the Shadow RAM, but I want to use the BIOS for FD READ.
To be honest, I don’t have the technical skills to directly control the FDC and read from the FD.

I'm sorry, i forgot you have to continuously keep reading from disk (don't have the luxury of read once and then forget)

By the way, do you know why we have to map it with MMR in order to control bank switching for SUB I/O ($D430)?
Even though it’s only 4KB, it feels like a waste to put more pressure on the main memory.

Because bank switching is only mapped on SUB I/O (unlike i.e. vsync flag), and to access the address space of SUB you have to use MMR (and halt SUB). The only alternative that i can imagine is a SUB custom command (or two commands) to change bank from within SUB itself. That, or using MSR register to have mapping for SUB I/O and then another mapping for VRAM pages, and swap them rapidly.
Also, you have some bytes to waste on the last page of shadow RAM, where it collides with MAIN I/O (i have tested and regardless of MMR mapping, MAIN I/O address are always working as expected)

Anyway, for the task (read disk and draw to bitplanes), it seems to me that mapping just 2 "pages" at a time (for VRAM), plus 1 fixed for SUB I/O, should be enough to do iterations for N bitplanes, and then at each iteration incrementing the MMR registers, and never touch mapped SUB I/O.
No need for the whole VRAM mapped, i think.

Originally, I planned to map only VRAM with MMR and control SUB I/O through shared RAM, but no matter what I tried, I couldn’t switch the bank.
(Even when setting SUB RESTART and disabling MMR.)

I don't know if i understand that correctly.
Shared RAM is (*) 128bytes hardwired to both CPUs (MAIN & SUB, at different addresses), but you can only access it from MAIN when SUB is halted (if not, writes don't work, and reads are dummy $FF's). You can use it to execute custom commands (i.e. what i mentioned earlier as an alternative), and that should work. Current bank should not change while video mode doesn't change. If you return control to F-BASIC, then i don't know, maybe it changes, but under your code, should not change.
And MMR doesn't """"need""" to be disabled, it would just not work while SUB is running. But in any case, with MMR on MAIN code will execute slower

If you have some code that doesn't work i could try.

By the way, how do you name the main 6809 CPU? MAIN or WORK? We here are used to MAIN, but i have seen both forms on documentation.

(*) I'm sure you know this much better than me , it's more like thinking out loud.

[KKTamu]

Anyway, for the task (read disk and draw to bitplanes), it seems to me that mapping just 2 "pages" at a time (for VRAM), plus 1 fixed for SUB I/O, should be enough to do iterations for N bitplanes, and then at each iteration incrementing the MMR registers, and never touch mapped SUB I/O.
No need for the whole VRAM mapped, i think.

By the way, how do you name the main 6809 CPU? MAIN or WORK? We here are used to MAIN, but i have seen both forms on documentation.

Thank you for your comment.

That's true!
In the first place, if you are splitting up the writes to the VRAM, there's no need to map 4 pages at once with MMR.
I thought switching pages would be cumbersome, so I mapped (fixed) 4 pages (16kbytes) at a time.

By 'main' I mean the free memory area of ​​the main cpu.

[KKTamu]

Execution Results of FD→ MMR DIRECT WRITE 40Lines x5

Drawing speed.
**30-sec movie.**
2.31 fps →2.0fps
Recording time: 6.71 → 7.5 min

The writing height at one time is set to 40 lines.
The flicker has improved a bit, but it's still not enough.

Next I'm going to set the writing height to 20 lines and then I'll be done with that.

Thank you,

[jimbobaby]

The writing height at one time is set to 40 lines.
The flicker has improved a bit, but it's still not enough.

Next I'm going to set the writing height to 20 lines and then I'll be done with that.

Yes, it's seems so. At this screenshot it's clearly that issue (color fringe happens between lines 40 and 80)

capture.png (183.92 KiB) Visto 389 veces

Reducing that to 20 would not be much better, i think. Double better, but not enough better .

In theory for a perfect drawing you could also use tile painting (some registers to put the byte RGB data -8 pixels-, and then write -or read, doesn't matter- only on one color bitplanes. Switch banks and repeat). But then you would have to draw in packs of 8 pixels, not even lines.

[KKTamu]

Reducing that to 20 would not be much better, i think. Double better, but not enough better .

In theory for a perfect drawing you could also use tile painting (some registers to put the byte RGB data -8 pixels-, and then write -or read, doesn't matter- only on one color bitplanes. Switch banks and repeat). But then you would have to draw in packs of 8 pixels, not even lines.

Thank you for your comment.

You're right.
The system I'm currently using involves writing directly to the mapped memory area on a file-by-file basis, which, thinking about it now, is quite inflexible.

If I want to write in 8-pixel units, it seems I'll need to fundamentally reconsider the drawing code.

This won't be possible right away, so I'll keep working on it patiently.

Thank you.

[KKTamu]

Execution Results of FD→ MMR DIRECT WRITE 25Line x8

Drawing speed.
**30-sec movie.**
2.0 fps →2.16fps
Recording time: 7.5 → 6.93 min

The writing height at one time is set to 25 lines.
The plan was to draw 20 lines, but the number of directories on the virtual floppy disk became full, so we had to give up. (If we re-created the floppy disk, we could handle 20 lines, but that is the upper limit in the current specification)
By changing from 40 to 25 LINEs, the flickering somehow became less noticeable.
Recording times have also been reduced.
I have set 'VM full power operation' to ON. This may be the cause.



Thank you,

[jimbobaby]

I have set 'VM full power operation' to ON. This may be the cause.

That's cheating . Just joking. I don't know if it speeds up evently both CPU's or could be timing concerns (not in this case, as you are using MMR for drawing).

If it's not messing with the capture timing, it helps, of course