Quote:

Tanni: Looking at your code, I can only draw one conclusion.. I have a long, looooong way to go. In the last couple of weeks, a lot of code that was wizardry to me makes quite a lot of sense now, so maybe in the future I'll understand yours as well.

Mirg: The way isn't that long as it seems. The code just looks quite impressing because its Turbo Pascal inline code with ASM mnemonics in the comment parentheses. As you work with an assembler program, you need just the contents of these parentheses and maybe some additional EQU instructions to introduce labels like EXPTPL. I never worked with an assembler programm, I just did inline coding in Turbo Pascal.

Let's have a look at the function VPeek, implemented in Turbo Pascal:

FUNCTION VPeek ( address : Integer ) : Byte ;

VAR value : Byte;

BEGIN (* VPeek *)
  Inline
  (
   $2A/address/     (* ld   hl,(address)  *)

   $FD/$2A/>$FCC0/  (* ld   iy,(EXPTBL-1) *)
   $DD/$21/>$004A/  (* ld   ix,RDVRM      *)
   $CD/>$001C/      (* call CALSLT        *)

   $32/value        (* ld   (value),a     *)
  );
  VPeek:=value;
END; (* VPeek *)

It has an integer parameter ''address'' which holds the address of the VRAM memory location to be read. There's a local variable ''value'' to hold the content of that address to pass it to TP. The inline code calls the function CALSLT, which is also provided beneath Turbo Pascal, where the whole 64 KB memory is RAM. CALSLT itself provides an interslot call. (There are two further but specialized routines doing also an interslot call, CALBAS for envoking BASIC and CALLF, call far, which is a shorter but not so general form of CALSLT.) The IX register pair holds the address of the routine to be called, here the RDVRM (read VRAM) routine. The VRAM address to be read by it is provided via HL register pair. I currently don't know why IY must be EXPTBL-1, but EXPTBL holds some values on the status of the slots. As RDVRM returns the byte read, it must be stored in variable ''value'' to pass it to TP. The other routines work quite similar.

The routines without inline code are some frequently used routines in a TP program. The procedure write_at could be faster, -- and I have also coded faster versions of it -- and uses the NAMBAS system variable located at $F922 to compute the VRAM start address of the string to be displayed. NAMBAS holds the start address of the name table, which is the current video screen memory in VRAM. I don't know why they've choosen this name! Maybe because the ''names'' of the characters displayed are there. By altering NAMBAS, you can switch between several screens. The write_at(1,1,blank) in the procedure ClearScreen wipes out the cursor which is located in position 1,1 after a ClrScr call. There's a possibility to switch off the cursor, but it didn't work, so I used that way to get a totally blank screen.

Quote:

Argh, of course! I completely misunderstood. My bad.

Can you please tell me the reason of your misunderstanding?

Quote:

Can you please tell me the reason of your misunderstanding?

Heh, I thought that this would actually work:

VDP98: db $98

I couldn't check because I was at work when I typed it, but *of course* that doesn't work. Using VDP98 in instructions like OUT(VDP98) will be translated to something like OUT($C003), and not (as I thought) like OUT($98).

Ah well, it's good to make a lot of mistakes at first. I'll get better eventually.

And thanks for explaning the Pascal-code. I don't quite understand the slots in MSX-memory yet, but the Compass assembler that rturbo kindly sent me has both a memory- and slot-viewer, so I'll go play around with those and the document about MSX-memory mentioned in one of my other threads.

It seems that you have BIOS-ROM enabled because you can call chget and chput directly. So you also can access the port bytes directly. If you use Turbo Pascal, slot 0 and slot 1 are set to RAM, so you must use CALSLT to envoke BIOS routines or even get some data like the port bytes. The CALSLT slows up the program. I should have read your postings more thoroughly.

Everything's going pretty well now. I decided to not program anything or look at other people's code for three days (since Friday evening) and then attempt to write a program that draws a line somewhere on the screen using only How to Program the Z80, the V9938 Technical Databook and an MSX BIOS calls chart as reference.

And I did it! \o/

I just coded what was described in the book, but I ended up with a vdp_write routine that's almost identical to the routine in the VDP tutorial on map.tni.nl. Probably just my brain remembering stuff that I forgot. I used SLA H instead of RLC H, though. I'll have to check, but I think SLA leaves some junk.. Ah well, almost got it right.

I do have a question about screens, though. What exactly is the difference between screen 4 and 5? They're both Graphic 4 Mode, but with a different LN-bit, right? I keep reading that games in screen 4 are hard as hell to code and fast, while screen 5 should be a stroll through the park to code, but a bit slow. As far as I understand from the V9938 Technical Databook, both screenmodes are pretty much identical, except for that LN-bit (192 / 212 lines).

You're screen info is not correct. Screen 4 is a pattern mode like screen 2, but with MSX2 color sprites. Screen 5 is a plain 16 colour graphics mode. The 192/212 lines bit is separate and works in every mode.