192KB VRAM HMMV routine

Page 1/3
| 2 | 3

By jltursan

Prophet (2520)

jltursan's picture

14-12-2013, 18:39

Has anyone a working example of copying from/to the extended VRAM?

I can't remember if setting the extended VRAM as source/destination in R#45 resets Y coord (using SC8, third page starts at Y coord=512 or Y=0 again) Question

Login or register to post comments

By Guillian

Prophet (3440)

Guillian's picture

14-12-2013, 19:19

I made the VRAM expansion about 20 years ago. I think Y start at 0 again.
I used this program to test it:

By Manuel

Ascended (17947)

Manuel's picture

14-12-2013, 22:32

FWIW: FastCopy 3 by XelaSoft also makes use of the extended VRAM.

By jltursan

Prophet (2520)

jltursan's picture

15-12-2013, 12:33

Thanks Guillian, this listing appears in the original japanese 192K VRAM upgrade article. It's a bit messy and it makes some strange things:

- It turns both images into black & whites ones by means of the LINE commands.
- The HMMM NX & NY values are, suposedly, wrong. SC12 has a width of 256 pixels and the command is setting 511. Also, NY value is 1535 (!), far higher than the maximum allowed. Anyway, they seem to work OK and do not disturb the command execution Question
- The images loaded, once recovered from expanded memory look ok; but it turned grainy, like a C64 screen (!).
- If I remove the LINE commands and thus disabling the B/W effect, I can see clearly that the images recovered suffered of some kind of bit masking, turning themselves into B/W with some color patches. I suposse that this overall behaviour has to do with the YJK SC12 uses. That's why I think the LINE commands were originally used, to mask this behaviour.

As OpenMSX works EXACTLY as the real machine (after tweaking the machine configuration adding the extra 64KB VRAM), I'm discarding a faulty VRAM IC or my own error assembling the upgrade. The following are the snapshots of the magazine example (with LINE commands deleted):


Now, a simpler program (slightly corrected NX & NY) to show it working with SC8. Again OpenMSX behaves like the real machine:

10 DEFINT A-Z
20 SCREEN 8:COLOR 15,0,0:CLS
30 REM VDP(9)=VDP(9) OR &B00000010
40 SETPAGE 0,0:BLOAD"sdf1.sc8",S
50 OD=&B00100000:GOSUB 100
60 A$=INKEY$:IF A$="" THEN 60
70 OD=&B00010000:GOSUB 100
80 GOTO80
90 REM
100 RESTORE:FOR I=33 TO 44:READ AD:VDP(I)=AD:NEXT
110 DATA 0,0,0,0,0,0,0,0,255,0,255,0
120 VDP(46)=OD
130 VDP(47)=&B11010000
140 FORI=1TO2000:NEXT:BEEP
150 RETURN


In SC8 it's easy to spot that even pixels are masked with the right most odd pixel values. Am I missing something??

@Manuel: Thanks!, there's also Chapuza Copy 2 and CopyCat that makes use of the extra VRAM; but...
- FastCopy: I've never been able to make it work (IIRC was something related to the FDC and previous configuration, must to test it again)
- Chapuza Copy: it never worked for me, it always reports free VRAM based in a 128KB setup. No idea of how it tries to detect the expanded VRAM. Maybe it's a clue that somethings wrong.
- CopyCat: I've never been able of find it... ;(

There's also a MIDI player; but it's of no use for me.

By Meits

Scribe (6396)

Meits's picture

15-12-2013, 13:30

As Xelasoft is Dutch, he made his software compatible with the most popular MSXes in Holland: Philips/Sony.

By jltursan

Prophet (2520)

jltursan's picture

15-12-2013, 13:35

That's it. Thanks Meits!

By Guillian

Prophet (3440)

Guillian's picture

15-12-2013, 14:11

I'm sure I used FastCopy on turbo R (and it recognized my VRAM expansion) Probably it was an enhanced version.

Your VRAM expansion is right. That's the expect behaviour.
The LINE command just discard the JK values (color) and keeps Y (luminance). That's why the images turns B/W.
Then the 64K expansion is used to store 2 images (128K). It is impossible to store 128K in 64K, so it stores half the information (= blocky image)

By jltursan

Prophet (2520)

jltursan's picture

15-12-2013, 14:24

Yep, a TurboR FastCopy version must exist... Question

About the VRAM used and talking about the SC8 example, this mode uses 64K for each page and 128KB can store two pages controlled by BASIC's SETPAGE (they have a logical height of 256 pixels; but without overscan, only 212 can be phisically visible).
If I add a third 64KB bank, why cannot store a full third page?, I don't see the reason of the info trimming... oO

By Guillian

Prophet (3440)

Guillian's picture

15-12-2013, 15:07

I'm guessing here: perhaps the VRAM expansion is not organized as we expect. So when using the COPY command, only 32K of the original image are copied to the expanded VRAM.

By jltursan

Prophet (2520)

jltursan's picture

15-12-2013, 15:15

What also puzzles me is that OpenMSX seems to "correctly" emulate the behaviour. So it must be a known VDP command engine quirk...

To configure the 192KB VRAM I've modified the hardwareconfig.xml file, changing the vram value in VDP tag, is it correct?

By msd

Paragon (1459)

msd's picture

15-12-2013, 16:07

I thought it had something to do with the interleaving of the memory. In screen 7 and up it does need 128KB, because one memory bank is not fast enough.

Page 1/3
| 2 | 3