Gameboy Development Forum

I ended up changing a few more things and got it to compile correctly.

First, I had to change all the large tile data unsigned char arrays to const, and that fixed the address overflow error.

Then I found that the fatal compiler error (I think) was due to two variables being declared in main() as "unsigned long". I changed it to "UWORD" and it compiled with no other errors (just the same warnings as above).

However, now when I load the GB ROM, I get a "Check Link" error that I don't know how to fix (I get the error even when connected correctly to a physical GB printer).

I can trace the error to the SendPrinterByte() function which lies in the comm.s file. Unfortunately I don't know ASM, so I'm stuck here.

Here's my attempt at converting the asm to C (there were also a couple other functions in that file, I tried converting them, too, because they seemed more straightforward (I just implemented them based on their name). It appears to be correct(?).

unsigned char GetLow(UWORD twoBytes){
  return twoBytes & (UWORD)0xFFFF;
}

unsigned char GetHigh(UWORD twoBytes){
  return twoBytes>>8;
}

unsigned char SendPrinterByte(unsigned char byte){
  unsigned char result;
  disable_interrupts();
  SB_REG = byte; //data to send
  SC_REG = 0x81; //1000 0001 - start, internal clock
  while (SC_REG & 0x80){} //wait until b1 reset
  result = SB_REG; //return response stored in SB_REG
  enable_interrupts();
  return result;
}

When I move these to the PrntCmd.c file, the game now correctly identifies the link cable and starts sending data/printing, but it only gives me this image:

(a blank line)

So now I'm trying to figure out what's causing that.

There's also a line in the main() function that declares a UBYTE e, but e is only used in the line "x = py+e+e;" in one of the for loops (and is never initialized nor changed). It is apparently Very Important, because if I take this out, the game stops sending data at line 6 and freezes there.

Tauwasser wrote:

No, GetHigh returns the high byte from the passed 16-bit word, GetLow returns the low byte from the passed 16-bit word. This might be related to your printing issue.

So they did do what I thought, I just implemented them wrong. My bad, haha.

Tauwasser wrote:

Make sure SB_REG and SC_REG are declared volatile.

SB_REG and SC_REG are basically macros for the addresses 0xFF01 and 0xFF02. They're defined in hardware.h as "(*(volatile UINT8 *)0xFF01)" (and FF02, respectively), so we're good there.

Tauwasser wrote:

I did not check if this actually compiles. All typos are yours to keep. GBDK-doc.pdf says memcpy is available, so why not use it.

I tried your main() code (and #included <string.h> for memcpy) and it looks like it compiles (and it's much more understandable, thanks!). The single line printing issue is still there, BUT, if you check out what it outputs now:

You'll see that it's a *slightly darker shade of gray*

I think the problem now lies somewhere in PrintTileData() in PrntCmd.c (or something with p_data). Currently trying to grok how that function works.

Thanks so much for your help, by the way. I've made a few games with gbdk but I'm still new to this kind of lower-level programming and I'm learning as I go. I'd really like my next game to use the printer and I feel like it's *almost* there.

edit: if I change &pic_tiles[bgtile] to just &pic_tiles in the memcpy call, I get a full-sized (160x144) light gray image...

edit2: I looked at the Game Boy Programming manual at how the printer receives data packets, so now the function at least makes sense, I'm trying to figure out if anything in here isn't working properly.

Last edited by Scazon (2015-06-17 15:02:03)

Scazon wrote:

Looking at main(), I think index should be a UWORD? Because there's 360 tiles total, and the index would wrap around at 255 if it were only one byte.

Yep, I didn't think that 18 by 20 might be >=256 .

Scazon wrote:

I don't know if that wraparound error is causing any problems (because it seems it should still print, but that the bottom of the image would be a duplicate of the first few rows).

It is a problem. But your analysis is correct, it should print the top half of the image twice.

Scazon wrote:

But either way, even if I declare it as UWORD, I wrote some debugging print statements that indicate it's still wrapping around at 255.

Try not doing index++ inside the pic_map[index++] statement. Instead, do pic_map[index]; index = index + 1; Maybe GBDK is doing a byte-increment only? Check the lss file to know for sure. Or disassemble the code and post it.

Scazon wrote:

Also, when calculating the checksum portion of the packet, it's supposed to be 2 bytes that represent the sum of the header and all contents of the data, but aren't you sending like 640 bytes of data per packet? (40 tiles * 16 bytes per tile). How can the checksum possibly contain that information with only 2 bytes? Unless I'm reading that part wrong..

Haven't looked at that part yet. But we copy 0x10 bytes (1 tile) to p_data, then call PrintTileData(p_data), so it shouldn't be 0x40 tiles per packet.

cYa,

Tauwasser

AHH ok I'm onto something. I did a complete rewrite of how the printer status is saved (because I don't think the original one was working as intended? And also I wanted to see if there were any errors in the status that weren't showing up). The CheckPrinterStatus and CheckForErrors functions were pretty much useless.

Anyway, I changed it so the PrinterStatus[] array is only two bytes (as it should be) and had it update only when sending one of the dummy bytes in a packet (because that's when the status is received). The first byte should always be 0x81, indicating the printer is connected, and the second byte should be 0 when everything's ok (with other bits giving different errors).

It managed to print this beautiful thing (I changed the default image data to my avatar):


So now I'm getting somewhere.

edit: i think the tile glitches are due to both index and bgtile wrapping at 255, which I still can't correct.

Last edited by Scazon (2015-06-18 12:41:41)

SUCCESS!



Wanna know how I fixed the overflow error?

if (index == 255){
  index = (UWORD)256;
} else {
  index = index + 1;
}

I'd like to know if there's a more reliable way to increment past 255, otherwise this is what I got.

Either way, thanks for the help! Now I can get started on my game. I'll probably also clean this up and post it as a 'newer' version of the printlib, since I had to make so many changes to it. I also want to change it to be able to easily print strings, and print one line at a time instead of waiting for a whole page.

My only doubt about that issue is that the code technically does wait for it to be ready to receive more data (the send byte function waits until the 7th bit of sc_reg to reset, meaning the serial transfer is complete). You do have to make sure the printer is physically ready before sending another print instruction (i.e. sending print data while it's still physically printing), but that doesn't happen in my code because it only sends 1 print instruction. There could still be a timing issue somewhere else though. I was having similar issues when trying to get it to print text (one char tile at a time)-- it would randomly replace some characters with others.. but I haven't seen a consistent pattern yet to figure out what's wrong.

I definitely want to redocument all this printer code, but I want to get a better library working before I do that. The game I want to make is gonna be a kind of interactive fiction, so I need to rework it to print text, and print single lines instead of whole images.

Doing that has been relatively easy so far, now that I got the bulk of it out of the way. Still trying to work out line feeds so that there isn't so much space between single lines of text (there's a certain way you have to send line feed data that's just a bunch of trial and error to test). I accidentally misplaced a bit and ended up with 18 printed lines of "Hello World!" when I just wanted one.

I did manage to get this, though, so it's coming along.

The printercommand(PRINTER_EOF) is only called once during a full screen print (at the end of ALL the tile data transfers). I rewrote the printerstatus function to update after every packet sent (20 tiles when printing a whole image, or 10 tiles when printing one line).

On the emulator, the status received indicates everything is alright. When I run it on the gameboy, it returns 8, which means "Unprocessed data present". So I guess that's it. Unsure how to resolve it though. Would it be just pinging the printer with status updates until it comes back clear? I'll try that. But also, the above printed alright even though it came back with that status, so I dunno.

Tauwasser wrote:

I wonder how many people actually still have usable printer paper though. I know I have a printer boxed somewhere with one roll of paper -- and I'm not sure it's still good.

All original printer paper should be expired by now. I have a few rolls, and they print spotty and faded. But because the printer is just a glorified thermal printer, you can use any old 1.5" receipt paper (or cut a longer roll to size). I got my rolls off Amazon here and it works fine.

Last edited by Scazon (2015-06-20 18:08:40)

Joancz wrote:

Hello,

First sorry for my bad english, i'm french

I have a problem with the printlib. i can compile my sourcecode, but that's all. Visual boy launch the GBrinter output image but it's all white. My real printer react to my roms, but don't print image...

If someone can ahve a look at my source code and help me

http://www.partage-facile.com/ZNU7ALAJG … b.rar.html


Thank you

i fixed the code, so it compiles in GBDK 2020
https://drive.google.com/file/d/1pEHIUL … sp=sharing