[SOLVED] My app keeps crashing/glitching

[Rafal]

I've created a bunch of routines for setting up the environment, reading files from cd, loading tmds, displaying sprites and models.

If I do individual sprites or models, it seems to be working fine (example in file first). But, then I try to load more files and things go haywire (second and third screenshots). Either I get Unresolved Exception Excode=0000000Ah or GPU timeout and then the app stops responding.

I've tried different things:
- First I thought it was due to memory allocation issue, so I've read about InitHeap3, malloc3, tried including mmgmnew.obj, played around with different heap values or not freeing the memory, but that didn't help
- Originally I was planning on allocating and setting up primitives (SPRT, POLY_GT3, DR_TPAGE, etc) upon startup (cause redoing it every frame just looks incorrect), but that didn't work. All that is visible in my previous commit here https://github.com/rafalgrodzinski/psx- ... 13ee2a1d30. The examples I saw used pre-allocated primitives buffer and set up primitives in each frame, so I've tried that as well (that's my latest attempt, visible in the main branch).
- I've tried reading up documentation, examples, or if someone came across similar issue, but I haven't managed to find anything that would help me.
- I thought that could be something to do with frame init/draw/buffer swap, so I played around with those, but that hasn't helped either
- Maybe there is something incorrect with my makefile or some configuration, but I'm not really sure

All the code is available in my github https://github.com/rafalgrodzinski/psx-playground. In main.c I've played around with loading different things, displaying them in different order, etc, so it's a little bit messy. I'm mostly suspecting the memory being overwritten somewhere, but I'm not sure how to check it further.

I'm quite new to PSX development so I'm not sure if there is some bug in the toolchain, I made a silly typo, or I misunderstand something at a fundamental level. I'm kind a at my wits end here. Any help is appreciated

[Rafal]

Right after writing the post I had an idea, what if instead of allocating and freeing memory when reading a file, I just keep a static buffer. It worked! It doesn't glitch anymore! The question is, why dynamic allocation didn't work?

Code: Select all

// cd.h
#ifndef CD_H
#define CD_H

#include <sys/types.h>
#include <kernel.h>
#include <libcd.h>
#include "types.h"

typedef struct cd_File {
  char *buffer;
  u_long size;
} cd_File;

void cd_init();
cd_File cd_load_file(char *filename);
void cd_free_file(cd_File file);

#endif

Code: Select all

// cd.c
#include "cd.h"

#define CD_SECTOR_SIZE 2048

void cd_init() {
  CdInit();
}

cd_File cd_load_file(char *filename) {
  cd_File result;
  CdlFILE file;
  int sectorsCount;
  //u_long *buffer;

  if(!CdSearchFile(&file, filename)) {
    printf("Couldn't find file %s\n", filename);
    return result;
  }

  sectorsCount = (file.size +  CD_SECTOR_SIZE - 1)/CD_SECTOR_SIZE;
  result.buffer = (char*)malloc3(SECTOR_SIZE * sectorsCount);
  printf("Reading file %s, %d sectors\n", filename, sectorsCount);
  
  CdControlB(CdlSetloc, (u_char*)&file.pos, NULL);
  //CdReadSync(0, NULL);
  CdRead(sectorsCount, (u_long*)result.buffer, CdlModeSpeed);
  CdReadSync(0, NULL);

  result.size = sectorsCount * CD_SECTOR_SIZE;
  return result;
}

void cd_free_file(cd_File file) {
  printf("Freeing 0x%08x\n", file.buffer);
  free3(file.buffer);
}

Since I tried both that setups primitives during rendering a frame and beforehand by allocating them and both worked fine, I guess there is something weird that the CDRead[\inline] does with the buffer. But maybe I haven't got the memory management setup properly?

[nocash]

This is wrong, InitHeap3((void*)0x801f0000, 0x00100000);
There is only 64kbyte of memory at 801f0000..801fffff, and your code tries to use 1024kbytes at 801f0000..802effff.
And, I don't know where your stack is located, but it might be also in that region?

[Rafal]

Hmm, I see...

In MMGMNEW.TXT it says

[2] Points of Modification
2.1
Memory control strategy
--> Until now the memory has been allocated from the bottom address toward the
top address, but in this object file the memory is allocated from the top
address toward the bottom address.

and

[4] Function

InitHeap3 Initializing a heap area

Syntax void InitHeap3( head, size )
void *head;
size_t size;

Arguments head Heap start address
size Heap size (a multiple of 4, in bytes)

I guess my assumption that since the memory grows downwards, the head would point to the top-most pointer is incorrect.

I've tried these settings:

Code: Select all

// system.cnf
stack=801f0000

Code: Select all

// main.c
InitHeap((void*)0x800f0000, 0x00100000); // also (void*)0x800efffc as I didn't know if stack & heap would overlap or not

Which I assumed would give me 64KiB of stack and 1MiB of heap, but it is still producing the same results.

Are these values still incorrect?

[nocash]

The stack does actually grow downwards, so you would want to set it to something like 801FFFFCh. For whatever reason, common values are 801FFFF0h or 801FFF00h. I think 80200000h should also work, although people tend to shy away from using such stack values.

I don't know if the heap grows upward or downwards, but the base address in initheap should be the bottom, you can see that your old code did use addresses above 80200000h in the screenshots that you had included in first post.

[Rafal]

I've tried

Code: Select all

STACK=80200000
InitHeap3((void*)0x800f0000, 0x00100000);

Code: Select all

STACK=80200000
InitHeap3((void*)0x800f0000, 0x00080000);

Code: Select all

STACK=801FFFF0
InitHeap3((void*)0x800f0000, 0x00080000);

Code: Select all

STACK=801FFFF0
InitHeap3((void*)0x800f0000, 0x000e0000);

Code: Select all

STACK=801FFFF0
InitHeap3((void*)0x80100000, 0x000e0000);

All of them are producing the same result

[Rafal]

I've figured it out, as expected it was a stupid typo on my part. Instead of

Code: Select all

result.buffer = (char*)malloc3(CD_SECTOR_SIZE * sectorsCount);

for CD_SECTOR_SIZE which I've defined as 2048, I've written

Code: Select all

result.buffer = (char*)malloc3(SECTOR_SIZE * sectorsCount);

which picked up the #define SECTOR_SIZE (512) from libcd.h.

At least I've learned something about how to set up memory correctly.

[Shadow]

The heap grows upwards and you can use some basic math to have it dynamically adjusted using the compiler/linker variables. The code below is just an example. Change the variables to your compiler flags as needed.

Code: Select all

EnterCriticalSection();
	InitHeap3(&bss_end, (((int)&sp - stacksize) - (int)&bss_end));
ExitCriticalSection();