Search results

I have SP2, and the same problem.

I always toyed with the idea of producing a handheld based footie management game, and make it as portable as possible so it could be run on various devices. Something harking back to the more simpler days of the 8-bits, rather than the insanely overly complicated managers you get today.

I took the same route Oankili uses, dev on VC6 as it lets you at least debug the damn code, and recompile and test occasionally to the real thing. I'd much rather do the debugging on the machine itself, but there doesn't seem to be an easy way to do that.

To test CPU usage in GPMadMp3, I had a debug version that timed certain key routines such as display code, SMC reading code, and most importantly the idle code. Since the nature of MP3 playback code requires you to do some hanging around, you have some idle time to measure. This should be true...

Vimacs, shush. :) Quo, you most likely need to scan for and remove the ID3 tag in the first file, it may be at the end (not even going to go into ID3 tags here, google for their spec, its complicated :)). Whatever player you are using probably gets to the end of the first file and then hits the...

I would also add, avoid all unregulated PSUs, they can damage sensitive electronic equipment (such as your GP32). They might be fine for a charging unit, but can result in damage to more expensive gadgets.

I wish people would stfu (pardon my rudeness) about backwards compatibility. I'd be amazed if GamePark gave a toss about it, and as a developer I don't give a toss about it either. Unless it was via an emulator, which I doubt we would see especially as even the windows GP32 emulator isn't good...

Hate to say this, and not trying to start a flame war, but compared to the PSP it looks pretty awful even if it does have the similar nice microswitched joystick as the GP32. The specs would have to really beat the PSP, or it be priced substantially less, before I'd consider buying one.

Doesn't the Gp32 run on batteries anyway? :P

Craig must have a BLU+ handy, surely. :) Mirko, if you could use the official source as a guide to calling the bios to setup the LCD, and it works fine on your GP32, Craig could test it.

Gnnnnh! GNNNNHHHH! Gamepark changed the make of the LCD panel, but they did not change the SDK did they, because their LCD init code works fine with both and clearly works with custom firmware as well. They aren't going to release a new GP32 version that doesn't work with their own SDK as it...

Let us assume the following for a moment: 1) Somebody somewhere has the source to the official SDK 2) The official SDK has no problems initing the LCD properly so it works on both the old and new units 3) Mirko's code is not initing the display properly, but was doing it enough to work with...

The official SDK only checks to see if it is known firmware, and only then as a bugfix for 16bit modes. Nothing to do with BLU-/+/+-/RW :P Just get mirko to init the LCD display the same way that the sdk does, if he hasn't already, then recompile. Also, does nobody have a clue about...

All the ones worth worrying about. :) Basically there are only 3 different types of Spectrums: The original 48k Spectrum with a beeper for a sound chip. The 128k Spectrum with the AY sound chip and pageable ram banks. The +3 Spectrum which is the same as the 128k but just has a disk drive...

Again, I disagree, obviously faster is entirely dependant on the compiler and the asm it generates after optimisation. Codewarrior for example doesn't compile that function to use ldms, it generates the following: MOV r2,#0 LDRH r3,[r1],#2 ADD r2,r2,#1 CMP r2,#0x12c00 STRH...

Um, forgive me for being so condescending, especially if I am about to be again. :) Why is it obviously slower than memcpy itself? C isn't an interpreted language, it is compiled into ASM, and I can't think of anything easier for a modern compiler to optimise when compiling than the simplest of...

Moral of the story, don't EVER EVER EVER measure the speed of your code using geepee32, to say it is inaccurate is an understatement. :P It scares me that anyone would ask such a question without being able to write it themselves, but anyway... this is from my mp3 player source: void...

I'm probably wrong, but I'm sure there have been a fair few discussions relating to reasons why you shouldn't set it to just anywhere. Mainly because certain areas of memory have certain settings with regards to the MMU that can make them much slower (or faster) to read/write.

Romarcade pacman roms are a combination of pacman and the original puckman set, sorry guys, should have listed all the roms needed in the readme. But it was all very last minute. :)

Are you setting the clockspeed at the start of GpMain, or are you setting it after you have initialised the LCD? You really should do it before initing the display, as vblank rates are based on clockspeed.