GP32 OK, another 32MB topic...why can't it be done?

[generalnmx]

Now that Gamepark is commericially dead, it may be up to us to upgrade it. After a talk with my computer architecture professor, I found I couldn't explain the issue well enough to him. Basically, this is what we agreed on:

- The device has a 32-bit processor, so it would be able to access 32MB of memory.

- The only problem would be the probable lack of enough wires between the CPU's register and the memory.

It is a 32-bit processor, so it should be able to access 32-bit instructions. Now, hearing this, blaming the EEPROM OS is not feesible, unless the OS for some reason ANDs off the leading bits of the addresses.

[EDIT] Re-reading Mr. Spiv's dump of the OS, it seems to use 32-bit addresses (which makes sense)...or was the dump sign extended?[/EDIT]

 

[Anarchy]

The only problem would be the probable lack of enough wires between the CPU's register and the memory.

This is not a problem. You only need to put a wire from the RAM to the CPU's Address 12.

 

[Hooka]

If you look at the bios dump by mr. spiv, you will notice there is a set of instructions to set the max memory and it's set at 8 MB, I'm not sure if just changing this would help or not but it's a start

 

[Anarchy]

Mr Spiv says that its more difficult than that.

 

[generalnmx]

Why was 8MB hard-coded into the OS? That doesn't make sense.

[EDIT]
OK, reading about it more, I think this OS was made by a crazy monk in a wine casket. Here's what I think is going on from Spiv's notes:

Here's the problem:

The user RAM area (0x0c000000-0x0c6fffff)
The system RAM area (0x0c700000-0x0c7fffff)

Gamepark got it backwards - usually the System RAM should be above the User RAM (what we can write to), otherwise the User RAM can't easily be extended. So what we'd need to do is move the System RAM to take up the last ~1MB of the 32MB. There might lie the problem - we'd be moving the starting address to the system RAM. Where else is the system RAM's address hard-coded?

And to NiN-Nin - Most OSes don't have an upper memory limit hard-coded except for the limit of their processor base (16-bit, 32-bit, 64-bit, etc.).
[/EDIT]

 

[NiN^_^NiN]

The system was made for 8mb of ram only so why doesn't that make sense?

h34r:

 

[Robster]

generalnmx, you're confusing the GP32, which is a fixed-function, non-expandable device, with a general-purpose PC which is designed to be expandable. Although, keep in mind that exactly the same issue faces PC software: There is 640kb of low memory space, followed by system ram, and then other ram starts above that. Modern OS's still struggle with that.

Now, if you want to add more RAM to the GP32, then (apparently, I haven't tried it) you just need to add a wire for A12. Then you can have user RAM from c000000 to c6fffff, system RAM from c700000 to c7fffff, and user RAM above that.

Because of the way GP32 executables are formatted, it would actually be pretty simple to write an FXE/GXB loader that would put the executable code in the low memory and put the data heap in high RAM. Then you could have a 7MB FXE file, and 24MB of data, and I think most games would work with it. Good enough?

BTW, a 32-bit processor can address 4GB of memory, more if it supports virtual memory. The CPU in the GP32 has some memory bus features that make designs simpler, at the cost of limiting the amount of memory: the maximum it can take in one bank is 32MB.

 

[generalnmx]

I'll admit it - I am not very knowledge when it comes to the insides of OSes. I was thinking of my work with Linux, and I guess I got it backwards. Thanks for the insight.

However, I am well aware of the 4GB upper limit, which is why I said it is normally only limited of the processor the OS was designed for. That is not really an "upper limit" imposed by the OS, its an upper limit imposed by the processor.

The Gamepark32 being a device designed for upgrading or not, it's very shortsighted to make it so inflexible. I was looking at it from a circuit design point of view - if you have the circuits for more memory, why not allow one to use them? Well, enough about that.

So you think we'd just need a modified FXE/GXB loader? Could you elaborate on that idea? You say it's simple, yet there I've heard there is a $60 prize from GP32Spain for a way to utilize 32MB of memory, and your comment is the closest thing to a real idea about how to solve the problem I've heard so far.

 

[Robster]

OK, what I'm talking about is the ability to malloc() memory above C800000. If your executable statically allocates too much memory (say, "char x[16 * 1024 * 1024]") then it's never going to work. But it should be possible to say char *p = (char *)malloc(16*1024*1024).

There are three issues:
1) getting the CPU to address and refresh the extra memory,
2) getting malloc to allocate memory in the high area, and
3) getting the CPU's memory management unit to cache the extra data area.

1) should just be a case of changing some of the CPU control registers. Changing the BIOS shouldn't be necessary, it will only use 8MB when it boots up and the unused memory won't be a problem.

2) GP32 executables have a table at the start, which says where in memory the program's static variables are located. For example:

c000000 - c01ffff executable code
c020000 - c02ffff initialised variables
c030000 - c03ffff uninitialised static variables *

The gxb/fxe loader sets the * area of memory to zero before running the program. However, the area of memory between the static variables and the system ram, is the heap. So the loader is going to store the location of the end of static variables somewhere, and this location is going to be the start of the heap (it's c040000 in the example). The modified loader would store 0x0c800000 as the heap start instead. Also, it will store the end of the heap somewhere as well. Hopefully this isn't hard-coded as c700000 in the libraries, but is stored in a location somewhere. The modified loader would set this location to the end of ram (in the 32MB case, it would be dffffff.

In a normal libc environment, there is a function called sbrk which does basic handling of the heap. When malloc doesn't have enough room for an allocation, it calls sbrk to get a new chunk of memory. malloc handles freed memory etc. sbrk also checks for out-of-memory. I had a quick look at the gamepark sdk libs, and there's no sbrk function in there, but there will be something similar.

3) I have no real idea about. Mr. Spiv's notes on the bios say that the memory outside the standard ram area is set as non-cacheable, and that makes sense, but I don't know if it can be made cacheable with the way the GP32 bios sets up the MMU page tables. If it can, then this part is easy. If it can't, then the loader has to set up new page tables (probably in the high ram) and set the CPU to use them. That's not so easy, but not impossible.

I guess I have to cop out here and say that I don't know 100% that this is all true but I've read the data sheet pretty thoroughly and I'd say it was a good start.

 

[mr.spiv]

Just few notes.. Adding some more RAM is ok assuming required modifications are made into BIOS. Someone lend me a modded GP32 and I'll do it <_<
Anyway after the BIOS part is ok there is still the issue of how to utilize it. SDK isn't capable of allocating memory from the "extended" memory due the braindead BIOS/SDK implementation (well.. lets say the current stuff works so it is kinda ok). Third party library/wrapped should also be implemented to take advantage of additional memory. One more issue is how to check the availability of extended memory. If I (or someone goes and mods the BIOS) it would work only for modded hardware. Current BIOS just blindly assumes some fixed amount of memory. That issue should also be taken care of somehow or otherwise there would be two versions of programs: one using extended memory and the other for vanilla GP32s.

 

[Robster]

I just don't get why the bios has to be changed. The thing is, most programs aren't going to benefit at all from the extra RAM. Specific games are designed for the 8MB, no need to change anything for them.

The extra memory would enable emulators to handle bigger ROMs. That's the only reason to do this mod - or am I missing something here? So there's only a handful of programs that need to be changed, and making them handle extra memory if it's available, or else fall back to the basic 8MB, shouldn't be hard.

I'll stick my neck out and say that there are NO programs currently existing that have any way of handling more than 8MB, even with a different bios. So, all the emulators have to be changed. And if they have to be changed, there's not even any need for a special loader. "Someone" could provide a special heap handling library which could be linked into an emulator, and which would handle the memory with basically no other changes required.

Please, mr. spiv or anyone else, explain why the bios would need to be changed, and what would be the benefit of doing it.

 

[Shadow of Chaos]

( off topic )

if this turns out to be possible and actually work what will we benefit from it? much better games able to run on it graphically? or just stronger apps etc?

Cheers..

 

[generalnmx]

Hmm, could anyone "lend" Mr. Spiv a modded GP32? Hey, it's for a good cause...maybe Mr. Spiv will split the $60 reward with you and you'll get your shipping back (if that reward is still valid)

 

[mr.spiv]

I just don't get why the bios has to be changed. The thing is,

It doesn't need to be changed.. you are perfectly correct in that. But BIOS is just a logical place to do it instead of requiring all programs to do their complete customs MMU setups. Afair it's not that many values that need to be changed... but my memory systems has malfunctioned lately pretty often :blink:
*cough* Personally it is more l337 & challenging to tweak existing code with strict space constraints than writing new stuff :lol:

 

[generalnmx]

Alright, I'll go tit for tat - if there's no reward from GP32Spain, I, myself, will pay for shipping + $2 through Paypal or something. Even international shipping.

So all we need is someone with a modded GP32 to send to the wonderful Mr. Spiv.

I'm very interested in this upgrade. I'd do it myself, but I don't have an extra GP32 to risk the modifications. If you do wish to do this, please be someone near Mr. Spiv ^^;

[EDIT]
May I remind everyone that this is also a buisness opportunity...I'm sure people would pay extra money for a 32MB GP32. Let's say the RAM costs $10, and shipping to a retailer costs $10, and Mr. Spiv gets $2 for "royalties", and you charge $5 for soldering the chip and making sure it works. Now that adds up to an extra $27, which isn't bad considering you're getting 32MB more. That $5 for you and $2 for Mr. Spiv can add up to a lot over time. If you want to go the bare minimum, even $1 or $.50 can add up to more then reasonable spending loot.
[/EDIT]

 

[Dolfhin]

*cough* Personally it is more l337 & challenging to tweak existing code with strict space constraints than writing new stuff :lol:

Tweak the GP32 So we might be able to get some more speed out you're GP32's?

Anyway whe're does Mr. spiv. live Would be nice to knwo if someone going to send him one

edit// changed mr psiv to mr spiv

 

[dad]

the actual words are soldering or solder, not sodering or soder.

$27 for a mod to a GP32 would be closer to $50 US or more. Replacement of an IC, like memory, is not an easy task and requires some expensive equipment to do a good job. It also assumes that a single, suitable 32Meg chip is easy to find and cheap. The GP32 is nice, but to spend money on mods just makes buying a PocketPC look better. The GP32 is a reasonable platform as it is, what would the extra RAM actually get us? shorter battery life?

...also, I'd wait a couple of months before declaring the GP32 commercially 'dead'

 

[generalnmx]

I'm mostly talking about prospects for an upgrade...when was the GP64i suppose to come out? 2007?

It all depends on where you get your circuits...I've been able to customize stuff for a lot less then $50 (not including the tools needed). I assumed those who do not have the tools could pay those that do a small fee to do the soldering. But, of course, we'd possibly be dealing with house brands and refurbished equipment.

And thanks for pointing out my typos. I changed them.

 

[Shadow of Chaos]

if anyone gets more info on this etc, plz make a new thread for us all to see.