MSXLib by Lieves!Tuore available

Champion (387)

16-08-2012, 20:21

If you happen to like cross development with SDCC (2.x), then MSXLib might be just for you. A collection of code snippets, most of them written in efficient assembly language, used in the latest L!T productions. No useless circle or line drawing trash, just fast VDP copy/set routines, keyboard/mouse/joystick handling, screen mode setting, VDP low-level bits, quick memset/memcpy, file reading plus some more. Get it through your favorite SVN client from:

svn://www.kameli.net/marq/msxlib

(The test program doesn't really do much useful)

By jltursan

Prophet (2619)

16-08-2012, 21:34

Nice, thanks!. Is it compatible with later SDCC versions?

By Marq

Champion (387)

16-08-2012, 22:31

I experimented a bit with SDCC 3, but quite a lot has changed, so you need to save more registers and the call stack frame isn't automatically set up as it used to be. SDCC 3 doesn't accept the same keywords as the older versions, either. There were some other problems, too, so I decided to give up, even if a lot of stuff was working already.

By PingPong

Enlighted (4175)

21-01-2013, 20:55

in the code there are some vdp routines (mostly msx2) that have a lot of nop. As pratically all msx2 users know the msx2 vdp is faster than msx1 vdp and does not need any nop, especially when doing out on 0x98 port

By Marq

Champion (387)

21-01-2013, 21:57

That's a good point there. There are slow and fast versions of the copy routines. The ones with nops are for MSX1 during the screen refresh - in the blank you can out as much as possible. However, I wouldn't say VDP2 is _faster_ per se, it just makes the CPU wait and won't trash the screen unlike VDP1.

By PingPong

Enlighted (4175)

21-01-2013, 22:45

Marq wrote:

On msx2 the cpu does not wait for anything. If you out too fast you get the same problems you have on msx1. The delay is just more short. On msx2 there is no hw mechanism that make the cpu wait when doing outs to vdp.
So to be more precise, the msx2 vdp does allow faster access than msx1 vdp, if you like.
But to allow faster access from z80 the vdp2 need to be faster in processing the access. And this is effectively true, giving the doubled vdp clock rate and the increased number of VRAM I/O slot in a specific time period.
Faster clock rate-> more memory accesses in a specific period -> short delay when processing outs from z80.

By yzi

Champion (444)

22-01-2013, 05:20

What routines do you mean?

By the way, I thought the VDP2 doesn't trash VRAM the same way the VDP1 does, when you out too fast. VDP2 just throws the outs away, but the VDP1 turns them into what looks like random garbage.

By Marq

Champion (387)

22-01-2013, 08:05

I guess I got messed up with tR/9958, where the processor actually waits (right?). Maybe time to run some real tests about VDP1/2. In "Adnukes" we had to deal with this a lot but the timings were crafted for VDP1 only.

By PingPong

Enlighted (4175)

22-01-2013, 22:03

Marq wrote:

Exactly! to summarize:

VDP1-> in active area there is no hw delay, you must delay via sw. If you go too fast you loose data.
VDP2-> in active area there is no hw delay, but vdp2 is able to keep up to a bunch of outi instructions, However, vdp2 cannot cope with a bunch of out (0x98),a
TR-> hw delay, so no problem

hope is clear now.

By PingPong

Enlighted (4175)

22-01-2013, 22:07

VDP2+ (meaning v9958) is a mystery for me. there is a wait line, but i do not know if this line is connected to z80, and which port are affected by this hw delay