The AB Project: Pac-Man

[The Usotsuki]

I decided I'd try my hand at a well-documented game, and would prototype it in BASIC.

 

Typical of me to try to do part of the attract mode first, prolly not actually wise.

 

Keep in mind: I really have no clue what I'm doing.

[JamesD]

One of the first things you need is some sort of timer where you can check the number of screen blanks that have taken place.
Those delay loops won't be the same on faster machines.
I'd start by replacing all the delay loops with a GOSUB and a single delay routine. Just set a variable for how long and make the GOSUB. It returns when that period of time has passed.
At first it could just be a FOR NEXT loop followed by a return.
Later you could change the subroutine to scan for VBlank with some assembly code through a CALL.
Once you get far enough just compile the BASIC with Einstein or the Beagle BASIC Compiler.
If you aren't comfortable enough with assembly you don't have to use it.
If a BASIC compiler isn't your thing and writing a large project in assembly is still a bit difficult for you, why not try CC65?
C should be fast enough for you.

FWIW, a free running 16 bit free running timer can be easily added to or based on the interrupt in the music player I gave you. Then just POKE 0 at the address of the timer to clear it and PEEK to read it.
Sadly, it would require a Mockingboard or mouse card and other mods since the Arcade Board has no timer and some work would be required to sync the timer to the VBlank on the Apple since every machine is different.

[The Usotsuki]

My intention is to use CC65, after prototyping in BASIC.

 

Not sure yet how I'd handle the full arcade screen, or if I'd rather go with the shrunken maze of the MSX version.

[The Usotsuki]

Like to add that a BASIC compiler really isn't an option because I'm using an & library (that I wrote =p).

 

Last night I started rewriting some of the & library core in C, where the code is actually a lot clearer.

[JamesD]

Like to add that a BASIC compiler really isn't an option because I'm using an & library (that I wrote =p).

Can't you still use user machine language calls? I thought ROM calls that assume you are calling from the interpreter were out but you could still use your own routines as long as you use different RAM than the runtime uses.

[The Usotsuki]

Well, the code I use takes parameters, and that's what isn't supported.

 

Anyway, I wrote a little demo in C (http://3.buric.co/libtesuji.c.txt) that tests a few features of the 9918 and could be used as the foundation. Next is to figure out how I'm going to implement the maze (my current thought is use a dump of the MSX tilemap at the beginning of a stage).

 

Kinda wish I had the source to the homebrew ColecoVision port or something else that might give me ideas of how to pull this off.

[JamesD]

FWIW, USR supports parameters if the compiler supports it.

 

 

You have to create a character set with the tiles that make up the maze.

I know there are some good tools to do that but I've never used them so I can't help you there.

Then use sprites for moving objects.

I think the fruit could be done with either.

 

I suggests you look through the Colecovision area for code examples. They will be Z80 but it beats trial and error.

One example:

http://atariage.com/forums/topic/168386-coleco-sprites-sample-assembly-codes-listing/

 

I have seen some complete MSX game source code but it's probably so large and complex you might have difficulty knowing where to start.

[The Usotsuki]

You have to create a character set with the tiles that make up the maze.

I know there are some good tools to do that but I've never used them so I can't help you there.

Then use sprites for moving objects.

I think the fruit could be done with either.

 

I suggests you look through the Colecovision area for code examples. They will be Z80 but it beats trial and error.

One example:

http://atariage.com/forums/topic/168386-coleco-sprites-sample-assembly-codes-listing/

 

I have seen some complete MSX game source code but it's probably so large and complex you might have difficulty knowing where to start.

I'm guessing the fruit is tiles, but it could be sprites (and for something like Ms. Pac-Man would have to be sprites).

 

I dumped the character set the MSX version uses (and I have a tile dump of the maze) - figure it's a start.

 

Drawing, at least, sprites is no big deal; as can be seen from the C code, I have that down. (it's what vdpdraw() does, and &DRAW in the BASIC wedge. The syntax is the same.)

[JamesD]

I'm guessing the fruit is tiles, but it could be sprites (and for something like Ms. Pac-Man would have to be sprites).

 

I dumped the character set the MSX version uses (and I have a tile dump of the maze) - figure it's a start.

 

Drawing, at least, sprites is no big deal; as can be seen from the C code, I have that down. (it's what vdpdraw() does, and &DRAW in the BASIC wedge. The syntax is the same.)

Where did you see vdpdraw?

I'm guessing you update local variables and vdpdraw dumps updates to the VDP but... without knowing what you are talking about I can't say for certain.

Edited February 21, 2015 by JamesD

[JamesD]

There appear to be some good topics in the TI-99/4A programming area.

I found this:

https://github.com/unhuman/GraphiCV

[The Usotsuki]

static void vdpdraw(byte n, byte x, byte y, byte c, byte a)
{
 word addr;
 byte al, ah;
 
 /* find start address */
 addr=0x1000|(((word)n)<<2);
 
 /* convert address to register format */
 al=addr&0xFF;
 ah=((addr>>&0x3F)|0x40;
 
 /* setup VDP address and mode */
 board[3]=al;
 board[3]=ah;
 
 /* write location */
 board[2]=y;
 board[2]=x;
 
 /* write character */
 board[2]=c;
 
 /* write attribute */
 board[2]=a;
}

It was in the file I linked earlier. It's the same as &DRAW in tms.a65.

[JamesD]

 

static void vdpdraw(byte n, byte x, byte y, byte c, byte a)
{
 word addr;
 byte al, ah;
 
 /* find start address */
 addr=0x1000|(((word)n)<<2);
 
 /* convert address to register format */
 al=addr&0xFF;
 ah=((addr>>&0x3F)|0x40;
 
 /* setup VDP address and mode */
 board[3]=al;
 board[3]=ah;
 
 /* write location */
 board[2]=y;
 board[2]=x;
 
 /* write character */
 board[2]=c;
 
 /* write attribute */
 board[2]=a;
}

It was in the file I linked earlier. It's the same as &DRAW in tms.a65.

 

That's just writing to the board registers by treating them like an array.

Think of board[2] as board+2.

 

So it's just writing out a command sequence to the VDP. I believe it's just writing a character to the bitmap.

Edited February 21, 2015 by JamesD

[The Usotsuki]

It's writing a sprite to the sprite table (the nth sprite, starting at graphic c, in color a, at location x,y). Like I said, there's an identical function in tms.a65.

 

There's a separate function, gputc(), for manipulating the tile map.

 

Manipulating a pointer as an array is a neat trick in C. Manipulating a pointer to a fixed address as an array, though, is just evil.

[The Usotsuki]

http://3.buric.co/ouch.dsk.gz

 

There's a couple things here.

 

First, run LOAD MAZE, which will set up the VDP and, well, load the maze.

 

DOT COUNTER will tell you how many dots (including energizers) are still on the board.

 

OUCH will show the dying animation.

[The Usotsuki]

 

Slowly...

[JamesD]

Check the August 1982 issue of BYTE magazine. Steve Ciarcia created a card with a 9918 for the Apple II.
It has plans and code.

[The Usotsuki]

The main difference is it channels the TMS9918 through 2 ports, instead of 4 (1 in each direction). This might make it a better target for replacing the TMS9918 with a V9938.

 

If there were some emulation of it, I could support it.

[Arbee]

If there's some test software for it (ideally on a .dsk/.do/.po image) it would take about 10 minutes to add to MESS. We also support the 9938, minus the collision registers. I could add a variant with that as well if you're interested.

[The Usotsuki]

There's some ASM stuff in that mag I could prolly try to build. According to the sample source in the Byte Magazine mentioned, Byte Magazine Volume 07 Number 08 - Logo (RESCAN) : Free Download & Streaming : Internet Archive, the "Register" port is C0x1 and the "Data" port is C0x0. (As opposed to the AB where read and write are separate ports? I don't see any reads done at all, but I'd assume read is channelled through the same ports as write?)

 

Oh geez, stuff in a 9938 and I'll be on that like white on rice.

 

I currently have an emulated Laser 128EX setup with a Mockingboard in 5 and an Arcade Board in 7 - if instead there were a Logo Card in 7 with a 9938...

[JamesD]

I'd go with a 9958 for the scrolling registers.

Some docs that might help with programming
http://www.konamiman.com/msx/msx-e.html#msx2th

[neglectoru]

What version of BASIC allows drawing text inside the graphics region?

[The Usotsuki]

There's tools for that (like Flex Type), and they're pretty transparent.

 

In the case of the programs I've been trying to write, I'm using an expansion board and writing on THAT instead of to the Apple screen - so the result looks like an MSX or a ColecoVision.

[Arbee]

A current MESS github pull adds 3 new cards:

 

ezcgi: Steve Ciarcia's original TMS9918 card, 16K VRAM at C0n0, read status/write registers at C0n1

ezcgi9938: Similar card with a TMS9938 with 192K of VRAM. VRAM at C0n0, read status/write command at C0n1, write palette at C0n2, write registers at C0n3.

ezcgi9958: Similar card with a TMS9958 with 192K of VRAM. Same registers as the 9938 version.

 

The original version runs the program listing from BYTE fine. I don't really have anything to program a 9938 or 9958 so there may be gremlins

 

Oh, and all 3 cards have the TMS's interrupt line connected, so if you enable interrupts on the VDP it should IRQ the 6502 appropriately.

Edited February 28, 2015 by Arbee

[The Usotsuki]

It's easy enough to get my code adapted for the EZ Color Interface.and I've in fact done that with the & wedge.

 

'me know when there's a build (I'm not sure my mingw environment can handle a MESS source tree) and I'll check it out, I'm interested especially in the V9938 mode.

[The Usotsuki]

Just rolled a copy.

 

The code I wrote for some reason isn't able to find the card, so I have it skip the detection, and assume slot 4...

 

with "ezcgi", it works.

 

with "ezcgi9938" and "ezcgi9958", I get a black display.

 

Well, it's a start.