nikodr,

The manual of AsMSX is only availaible in spanish, although I started to translate it in french a while ago, but never had the time to finish it. However, I found the spanish manual quite easy to understand. You will find it along in the 0.12g zip file as I trust that nothing much changed between 0.12g and 0.15a, as the later versions mainly dealt with core bugs.

To generate a .bin file in asMSX, just put the following at the top of your code :

. BASIC
. ORG 0xaddress
. START startaddress

Quote:

1) Download PASMO to assemble on a PC 2) Download Notepad++ to create files 3) Use this "template" --- CUT HERE --- INITTXT EQU #006c INIT32 EQU #006f INITGRP EQU #0072 INIMLT EQU #0075 CHPUT EQU #00A2 org #4000 db "AB" dw start db 00,00,00,00,00,00 start: call INITTXT LD HL,texto loop: LD A,(HL) call CHPUT inc HL ld a,0 cp (HL) JR NZ, loop fim: jp fim texto: DB 'Hello World of MSX! Im SDW and I just got my NMS 8245 ',00 END --- CUT HERE --- RAM is *probably* after $c000 Save that as mycode.asm Go to DOS and use pasmo mycode.asm myfirst.rom use the .ROM on BlueMSX or OpenMSX... That's it. Direct and easy!

Was not ...

"org #4000
db "AB"
dw start
db 00,00,00,00,00,00,00,00,00,00,00,00"

Programs could start at 4010!The 'important' part is AB, later the start address for example :
41,42,10,40,00,00,00,00
00,00,00,00,00,00,00,00
program start here (4010) ...

If you are interested into programming for MSX home computers. It would be possible to pay $$$ to me and get a license to get some samples on disks ...

Or just seek for Books. After all, the difficulty could improve the intellectual levels of individuals !!!

Just check the book THE MSX RED BOOK.
MSX-BIOS routines.

Change mode:

LD A,1 ;screen mode (0,1,2,3)
CALL 005FH; CALL CHGMOD

Write VRAM (This works like the VPOKE):
LD A, dd ; dd is the byte number (ASCII character)
LD HL,dddd ; dddd is the VRAM address
CALL 004DH ;CALL WRTVRM

Read VRAM (This works like the VPEEK):
LD A,dd ; byte
LD HL,dddd ;VRAM address
CALL 004AH ;CALL RDVRM

If you wanted to use OUT's with the bytes to the VDP data port, just set the begin address and output the bytes. It is recommended to use some sort of delays or the BIOS routines for send data to the VDP.

Set Read:
LD HL,dddd ;VRAM address
CALL 0050H ;CALL SETRD

Set Write:
LD HL,dddd ;VRAM address
CALL 0053H ;CALL SETWRT

Use OUT 98H to send the data byte.

Screen 0:
40x24 text mode.
Characters on screen VRAM 0000H-03BFH (960 bytes).

Screen 1:
32x24 text mode.
Characters on screen VRAM 1800H-1AFFH (768 bytes).

Just change the screen to one of the text modes and write the bytes to the correct VRAM address to see the results.

Alright, I have manged to get a little charplasma going now (that's the democoders equivalent of Hello World! )

I'm still a bit confused on the VDP though. I read somewhere that you could only access VDP during the vertical blank period, otherwise you would get lockups...?
I did some tests with a loop that constantly wrote to VRAM using the VDP, and it seemed to work fine, have I misunderstood something?

Speaking of VBL, I also wanted to find a way to wait for VBL to time my effects. There seems to be a standard interrupt that kicks once per frame, so I did like this

ei
halt
di

(Enable interrupts, wait for it, then disable again)

Is that a sensible way to make a VBL wait?


Then I do have some issues with setting gfx modes. The BIOS way works fine to set Screen 1 (32x24 text mode). However when I set Screen 0, I get 40x24 as expected in emulator, but on my real MSX (NMS8245) instead I get some kind of MSX2 mode with 80 characters wide screen.

I also tried setting modes with the VDP directly, using the code hitchhiker posted, but then I only get garbage on screen no matter what mode I try. Strange...

Quote:

Alright, I have manged to get a little charplasma going now (that's the democoders equivalent of Hello World! ) I'm still a bit confused on the VDP though. I read somewhere that you could only access VDP during the vertical blank period, otherwise you would get lockups...? I did some tests with a loop that constantly wrote to VRAM using the VDP, and it seemed to work fine, have I misunderstood something?

when working on a msx2 @3.5Mhz (V9938 VDP) you can output data to vdp at full z80 speed, even outside VBLANK, no problem at all.
when working on a msx1, (TMS VDP), the maximum speed you can achieve depends if you are in vblank or not.
outside vblank, every byte write or read should wait almost 26 z80 T-States (including the instruction that write data to VDP port 98h)
in vblank, no limit or delay.

For waiting for interrupts the tecnique below is OK, however i do not know why you disable ints

ei
halt

Quote:

Then I do have some issues with setting gfx modes. The BIOS way works fine to set Screen 1 (32x24 text mode). However when I set Screen 0, I get 40x24 as expected in emulator, but on my real MSX (NMS8245) instead I get some kind of MSX2 mode with 80 characters wide screen.

Umh, may be the real machine remember the width of screen so calling the bios to set screen 0, remember the 80 char width. the width is stored on the CMOS RAM. maybe if you do in basic (on the real machine):

Screen 0
Width 40
SET SCREEN : REM SAVE ON CMOS BATTERY THE WIDTH of 40

Quote:

I also tried setting modes with the VDP directly, using the code hitchhiker posted, but then I only get garbage on screen no matter what mode I try. Strange...

to get a good setup of the screen mode, you need also to intialize the VRAM....

Quote:

I did some tests with a loop that constantly wrote to VRAM using the VDP, and it seemed to work fine, have I misunderstood something?

Did you do this on a real MSX? IF so then you have a very strange MSX
If you write to vram at same time the VDP is building the screen you'll get distortions.

Quote:

ei halt di

This works fine if only the VDP generates interrupts. But if you plug in additional hardware which also generates INTS you wont be able to tell if it comes from the VDP on not.

Quote:

Then I do have some issues with setting gfx modes. The BIOS way works fine to set Screen 1 (32x24 text mode). However when I set Screen 0, I get 40x24 as expected in emulator, but on my real MSX (NMS8245) instead I get some kind of MSX2 mode with 80 characters wide screen.

The 80x24 is set by setting:

ld a,80
ld (&hf3ae),a ;width 80

when calling the bios for textmode,it will look at that address to determine the width.

Quote:

I also tried setting modes with the VDP directly, using the code hitchhiker posted, but then I only get garbage on screen no matter what mode I try. Strange...

If setting the mode yourself through the vdp-regs then you'll have to wipe clean the vram yourself. If you do it through the bios,the bios wipes it for you.

Quote:

when working on a msx2 @3.5Mhz (V9938 VDP) you can output data to vdp at full z80 speed, even outside VBLANK, no problem at all. when working on a msx1, (TMS VDP), the maximum speed you can achieve depends if you are in vblank or not. outside vblank, every byte write or read should wait almost 26 z80 T-States (including the instruction that write data to VDP port 98h) in vblank, no limit or delay.

Ahh! OK, that clears things up and makes more sense. The code I was testing with was my plasma code that actually does a bit of calculation for each output:

	ld a,ix+XP
	add a,b
	out (c),a

Haven't counted how many T-states that is, but if I recall correctly the ix instructions takes quite a few.
And then I was testing it on my MSX2, but it would be nice to be able to write code that is MSX1 compatible.
Am I right in assuming that no emulator emulates this correctly, so the only way to know for sure that you don't stress the VDP too much is to test on a real computer?

Quote:

For waiting for interrupts the tecnique below is OK, however i do not know why you disable ints ei halt

My thought was that I didn't want an interrupt going off when I was doing my VDP stuff, since I read that it could mess things up, but as long as I finish my code before next VBL, I guess it shouldn't be a problem having interrupts on all the time.

Quote:

to get a good setup of the screen mode, you need also to intialize the VRAM....

The rest of the program was the same as before, so the VRAM has stuff written to it.
Ie. before I had like this:

1) Set Screen 1 using BIOS
2) Do effect

and I instead changed to

1) Set Screen1 using VDP
2) Do effect

And only got garbage.

Quote:

This works fine if only the VDP generates interrupts. But if you plug in additional hardware which also generates INTS you wont be able to tell if it comes from the VDP on not.

OK, what is the correct procedure for a VBL wait if you want to be compatible with expanded units?


Also, thanks to everyone for helping out. I apologize for bombarding you with all these newbie questions!

Quote:

when working on a msx1, (TMS VDP), the maximum speed you can achieve depends if you are in vblank or not. outside vblank, every byte write or read should wait almost 26 z80 T-States (including the instruction that write data to VDP port 98h)

Actually, it's not 26 T-states but 29 T-states (8µs @ 3.579545 MHz)

Quote:

ei halt di (Enable interrupts, wait for it, then disable again) Is that a sensible way to make a VBL wait?

This method should work ok, if you don't have MIDI or some other devices generating ints. How ever EI has effect in one command delay, so I think the code should be:

EI
NOP
HALT
DI

Another thing ... If you like demos, probably you will use the PSG too.

There is the infamous "malware" that apparently was even spread to some MSX cartridges and books when the programmers do not correctly set the bits on the registers. Since the PSG is used to read from the game ports a program should not mess with the I/O part. This is even more important than the Video timing on non (MSX2) MSX-Video processors ... This was/is rumoured to be potentially dangerous to the MSX microcomputer.

Quote:

Another thing ... If you like demos, probably you will use the PSG too. There is the infamous "malware" that apparently was even spread to some MSX cartridges and books when the programmers do not correctly set the bits on the registers. Since the PSG is used to read from the game ports a program should not mess with the I/O part. This is even more important than the Video timing on non (MSX2) MSX-Video processors ... This was/is rumoured to be potentially dangerous to the MSX microcomputer.

The term 'malware' is a bit exaggerated. 'Malware' refers to software that intentionally damages the system, and as far as I know, no MSX software was written with the intention to damage the computer it runs on.

The two upper bits of register 7 of the PSG control the function of its two I/O ports, of which the values are in regs 14 and 15. Port A (reg 14) must be configured as input, port B (reg 15) as output, meaning that register 7 must always contain %10xx xxxx. On some MSX1 models the lines to the joystick ports are not buffered, which means that an incorrect set up of register 7 could, indeed, potentially blow up the PSG.

Quote:

Quote: ei halt di (Enable interrupts, wait for it, then disable again) Is that a sensible way to make a VBL wait? This method should work ok, if you don't have MIDI or some other devices generating ints. How ever EI has effect in one command delay, so I think the code should be: EI NOP HALT DI

Almost every MSX device creates interrupts : floppy disk drive, FM Pac, Music Module, ...
Therefore, you should not use halt to wait for a VBLANK interrupt.

Quote:

Quote: Another thing ... If you like demos, probably you will use the PSG too. There is the infamous "malware" that apparently was even spread to some MSX cartridges and books when the programmers do not correctly set the bits on the registers. Since the PSG is used to read from the game ports a program should not mess with the I/O part. This is even more important than the Video timing on non (MSX2) MSX-Video processors ... This was/is rumoured to be potentially dangerous to the MSX microcomputer. The term 'malware' is a bit exaggerated. 'Malware' refers to software that intentionally damages the system, and as far as I know, no MSX software was written with the intention to damage the computer it runs on. The two upper bits of register 7 of the PSG control the function of its two I/O ports, of which the values are in regs 14 and 15. Port A (reg 14) must be configured as input, port B (reg 15) as output, meaning that register 7 must always contain %10xx xxxx. On some MSX1 models the lines to the joystick ports are not buffered, which means that an incorrect set up of register 7 could, indeed, potentially blow up the PSG.

Actually, I believe that the newspaper reported this as some sort of "Virus" ... Sure that since it was already reported, most of the contemporaneous programs are corrected before getting a cartridge release.

I do not know if it was 'intentional' or not ...

Quote:

Quote: when working on a msx1, (TMS VDP), the maximum speed you can achieve depends if you are in vblank or not. outside vblank, every byte write or read should wait almost 26 z80 T-States (including the instruction that write data to VDP port 98h) Actually, it's not 26 T-states but 29 T-states (8µs @ 3.579545 MHz)

No, i tested on the unfamous Sony HB-10P with the vdp clone. (write of 6144 bytes continuosly) This model is knew to be the slowest in VRAM Access.. With 26T-States there is no corruption even with ALL SPRITES ON (the worst case)
(i have 32 sprites of 16x16 pixels on screen arranged on a 4x8 matrix)
So the effective time is about 7.2 us