Doubts about 9938 commands

Champion (468)

07-02-2021, 16:34

Hi guys, I was reading the 9938 manual (http://rs.gr8bit.ru/Documentation/V9938-programmers-guide.pdf) and had some doubts about the VDP commands:

The HMMM (High speed move VRAM to VRAM) and YMMM (High speed move VRAM to VRAM, Y coordinate only) are pretty straightfoward, as they copy a rectangular area from one place to another, the pictures clearly explains the commands.

But, what about the HMMC (High speed move CPU to VRAM)? What it does actually? I can't understand the source, the doc says "The first byte transferred from CPU after starting executing the HMMC command should be located in color register R#44 (CLR). Format of color data depends on the graphics mode."

It will fill all destination area with this byte?

What is the difference between HMMC and HMMV (High speed move VDP to VRAM)?

Entrar ou registrar-se para comentar

Por Daemos

Prophet (2052)

07-02-2021, 17:12

Hmmc copies data from your ram to the vram. The destination is a xy square in the vram however your source is a starting adress in ram. You then out your data byte by byte until you have everything you need. The first byte you out will be at the start of the adress where your gfx data is.

Por Daemos

Prophet (2052)

07-02-2021, 18:38

The other command HMMV SImply fills an area with one single color. So you basicly tell the VDP to fill up that area for you. Very handy when you for example quickly want to fill a part of the VRAM area with background color or want to clear the VRAM.

Por Grauw

Ascended (10721)

07-02-2021, 18:43

The data for each (pair of) pixel(s) is fed through VDP register 44. You need to make sure the first byte is already set in the register when the command is executed, it will be drawn immediately, then signals TR to the CPU and wait for a new byte to be set. Then officially the CPU has to to poll TR before setting the next byte, however in practice you do not need to wait for this, the VDP transfer is fast enough to keep up with the CPU. The most convenient way to set new values to r#44 repeatedly is via the indirect register access (see section 1.2).

Por aoineko

Paladin (904)

08-02-2021, 11:01

To sum up:
- HMMC: Copy a linear buffer in RAM to a 2D area in VRAM
- HMMM: Copy VRAM area to somewhere else in VRAM
- HMMV: Fill VRAM area with a given color
- YMMM: Copy a VRAM strip to somewhere else in VRAM with same Y coordinate

YMMM is not so easy to use because you cannot define a closed area: the area will always extend to at least one of the right/left edges of the screen. This is especially useful for vertical scrolling when you want to copy full lines.

I don't know if it was already clear, but just in case: for the HMMC command, the first byte of data is sent in the color parameter of the command (R#44). The following bytes are sent by indirect sequential writing to register R#44. So, if you want to send a 10 x 10 pixels image, you have to put the first byte in the command and then send the remaining 99 bytes.

One last thing: You have to pay attention to the unit used for the source color of each command. HMMC and HMMV use the "byte" as the unit while LMMC, LMMV commands, for example, use the "dot".
In all cases, you send the data in a byte, but this changes the number of dots you send in each byte and the way they are encode, depending on the screen mode (and its number of bits per color).

For 4 colors screen mode (2-bits per color like Screen 6):
- Byte unit: 1 byte = 4 colors [c1|c1|c2|c2|c3|c3|c4|c4|c4]
- Dot unit: 1 byte = 1 color [xx|xx|xx|xx|xx|xx|xx|c1|c1]

For 16 colors screen mode (4-bits per color like Screen 5) :
- Byte unit: 1 byte = 2 colors [c1|c1|c1|c1|c1|c2|c2|c2|c2|c2|c2]
- Dot unit: 1 byte = 1 color [xx|xx|xx|xx|xx|c1|c1|c1|c1|c1]

For 256 colors screen mode (8-bits per color like Screen 8) :
- 1 byte = 1 color (in all cases)

This also changes the number of bytes to be sent with the HMMC command. For an image of 10x10 pixels, 100 bytes must be sent in Screen 8, 50 bytes in Screen 5 and 25 bytes in Screen 6.

Por jltursan

Prophet (2619)

08-02-2021, 10:37

Quote:

Then officially the CPU has to to poll TR before setting the next byte, however in practice you do not need to wait for this, the VDP transfer is fast enough to keep up with the CPU. The most convenient way to set new values to r#44 repeatedly is via the indirect register access (see section 1.2).

Is the VDP fast enough to keep sending data even with known faster CPUs (Panasonic turbo mode, 7MHz mods, etc.)?

Por ericb59

Paragon (1099)

08-02-2021, 12:58

For HMMC it copy data from Ram to VRAM
The Ram address where data are stored must be set to HL register.a
Then you must use a loop to transfer each byte.

Por Grauw

Ascended (10721)

08-02-2021, 12:58

jltursan wrote:

Quote:

Is the VDP fast enough to keep sending data even with known faster CPUs (Panasonic turbo mode, 7MHz mods, etc.)?

Yes, because all faster CPUs will use a throttling mechanism when accessing the VDP ports.

Por jltursan

Prophet (2619)

08-02-2021, 13:03

Cool, thanks Grauw!

HMMC it's not a speed demon but definitely faster than having to setup write VRAM pointers all the time

Por Metalion

Paragon (1622)

08-02-2021, 13:45

jltursan wrote:

HMMC it's not a speed demon but definitely faster than having to setup write VRAM pointers all the time

Well you have to set up the registers for the HMMC command as well, so it's about the same. The real advantage of HMMC is that you can send linearly data that will be stored non-linearly in VRAM. For example, a 32 bytes long data set that will be displayed as a 8x8 char in SCREEN 5.

Wait ... Perhaps that's what you meant?
lol ... I must be tired !

Por Grauw

Ascended (10721)

08-02-2021, 14:12

Another advantage is that you can use HMMC in parallel with VRAM access. One use of this is to transfer data stored linearly in one place of VRAM to a rectangular area elsewhere through the CPU. Or to use only HMMC in the main program loop, and VRAM access on the interrupt handler, so the interrupt never needs to be blocked.