9 replies to this topic

[flyingfisch]

MPoupe posted on Cemetech about his new game, CGDoom.

It is still rather buggy but definately playable.

Screenshot:


Videos:

Running on emulator:


Running on KermM's PRIZM, not overclocked:



Download
http://www.cemetech....p...file&id=755

[Forty-Two]

Wow! That's realy cool. Do you know if he plans to enter it in the contest? That'd definitely be tough competition.

[flyingfisch]

I asked him and he didn't reply...

[Martin]

Updated version is at http://www.omnimaga....68.0;msg=256372

[MicroPro]

Martin, I'm really curious to know what is the simulator you put in the archive? Did you write it? Is it an SH virtual machine or is it native x86 code?

[Martin]

Hi,
the simulator is written by me - it is x86 application, it's main purpose is to debug the application on platform with debugger (windows). It contains small library simulating Prizm functions on PC so I can compile the same sources for both PC & Prizm.
I released source code for the simulator library with CGPlayer - check here: http://martin.poupe.org/casio/
Of course I will release sources for CGDoom after it will be somehow "finished", also with the simulator.

Another post about my simulator is here: http://www.omnimaga....hp?topic=9433.0

[flyingfisch]

Hi,

=====BUG REPORT=====
On my calc, when I try to get to the second level, by pressing EXE' /> in front of the switch, I get this error:

ERROR:
Z_Malloc: failed on a

It seems that the rest of the text goes off the screen.

On my cousin's calc and my brother's calc, it only happens when trying to get to the third level.

I am using the default doom.wad file.

[Martin]

Hi,

ERROR:
Z_Malloc: failed on a

Hello,
Doom requires 8MB RAM. I did some hacks to run it on smaller RAM, but I never got to the level 3. So the crash is expected, probably the level is larger than the previous levels.
To save RAM I use flash directly. But if the Doom requests block of e.g. 8KB from wad on some offset, I try to find it in the flash. If the block is continous, then I can use flash (= no RAM allocation). But if the wad has more fragments (file fragmentation) and the requested block is in 2 different fragments, I cannot use flash, I have to malloc these 8KB and copy the data here. So try to defragment your calculator storage - it may help.

But it is possible that the problem is elsewhere, the CGDoom state is less than alpha !

[MicroPro]

Hi,
the simulator is written by me - it is x86 application, it's main purpose is to debug the application on platform with debugger (windows). It contains small library simulating Prizm functions on PC so I can compile the same sources for both PC & Prizm.

I see. So you implemented prizm-specific functions for Windows, but that required many changes to the actual source code.
Actually (after seeing the Cemetech SDK) I thought about implementing prizm functions in Windows and release it as a library that users can simply link the same g3a source code against it to have the Windows executable. Don't you have the same idea?
mini-SDK is smaller and should be much easier to do this.

To save RAM I use flash directly. But if the Doom requests block of e.g. 8KB from wad on some offset, I try to find it in the flash. If the block is continous, then I can use flash (= no RAM allocation). But if the wad has more fragments (file fragmentation) and the requested block is in 2 different fragments, I cannot use flash, I have to malloc these 8KB and copy the data here. So try to defragment your calculator storage - it may help.

Not sure if I understand this correctly, but how about doing address translation? i.e mapping a continuous virtual memory space to the flash area and have all mallocs use that mapping?

[Martin]

I see. So you implemented prizm-specific functions for Windows, but that required many changes to the actual source code.
Actually (after seeing the Cemetech SDK) I thought about implementing prizm functions in Windows and release it as a library that users can simply link the same g3a source code against it to have the Windows executable. Don't you have the same idea?
mini-SDK is smaller and should be much easier to do this.

Not sure if I understand this correctly, but how about doing address translation? i.e mapping a continuous virtual memory space to the flash area and have all mallocs use that mapping?

Hello,
1. the CGplayer used "unfinished" simulator, so the source needed to be modified. But CGDoom really use the same sources for both calculator + PC simulator. See here: http://martin.poupe....doom0.03src.zip
I think we had the same idea :-)

2. I have no knowledge of virtual memory on Prizm. I do it simple way, you will see it in the source code, see cgdoom.c, function CreateFileMapping(). But you are right, map file to continuous memory space would solve it. But in most cases there would be few fragments, so the improvement would be small. And there are many required buffers in true RAM. Do we have some updated map of memory, list of areas, which can be safely used in addin ?
I use heap, system stack, VRAM (as VRAM) and background VRAM (for menu handler). I think I could create file in main memory and use it as a buffer (max ~ 60KB), but I would like to find more unused memory :-)