But It was QZ80 code I was interested in as it is much faster - Give better performance for emulating GAMEBOY CPU.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
With striped CPU code it is maybe posible emulate entire GAMEBOY in only HUB memory.
As it not use entire 8080/8085 memory space.
Most code RUN in BANCK addresed memory with relatively small window to it.
On Black/white LCD display window is only 2 KB to
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
But It was QZ80 code I was interested in as it is much faster - Give better performance for emulating GAMEBOY CPU.
Regards
Christoffer J
Christoffer,
the difference isn't dramatic, but perhaps 10-20%. As I said before, I may rewrite the 8085 emulation based off of the new qz80 code. After all it's just ripping out lots of code and changing some flag register peculiarities and the interrupt code. I've done that with the current ya85 code and it should be just as easy with qz80.
Sapieha said...
With striped CPU code it is maybe posible emulate entire GAMEBOY in only HUB memory.
Hmm.. I'll add a #define for a Propeller board without external memory then. You will need to use a memory access map like I did in TRS80 to map the rd_byte and wr_byte addresses. I used a resolution of 1K pages for TRS80, because 1K is the smallest unit with different meaning in the address space. The screen memory there is 1K, as is the keyboard matrix. This indirection of course slows down every memory access by several instructions and an additional hub RAM access, but you can't get around this.
For the M100 it was sufficient to distinguish between 1st 32KB (ROM) and 2nd 32KB (RAM), because all I/O there is through ports, not memory mapped. All I had to do was to prevent writing to the 1st 32KB.
GAMEBOY mostly use Memory mapping in 2 KB units. NOT sure now if RAM/ROM has 2KB else 4/8 BUT-
One window for RAM one for ROM and one for Display.
Rom code bigger as one window On cartridge are addressed as Bank's by special decoder on cartridge.
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
GAMEBOY mostly use Memory mapping in 2 KB units. NOT sure now if RAM/ROM has 2KB else 4/8 BUT-
One window for RAM one for ROM and one for Display.
Rom code bigger as one window On cartridge are addressed as Bank's by special decoder on cartridge.
Regards
Christoffer
With 2K banks you need 32 bytes (or perhaps words) for the rd_byte/wr_byte remapping. Just take a look at qz80 how it's done if TRS80 is defined. There is a dispatcher that discards 10 bits of memory address and jumps to the appropriate code to handle the read or write for the given address. As long as things don't get too complicated, all that code should (or rather must) fit in the cog.
I'll go and copy qz80 over to m100 and start stripping it rather than going to the pub today. That has the advantage to save me some money
You spare money - I time to find all places to remove unnecessary code in it. As You can that places know alread
Then we can look on special instructions that this CPU have.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha said...
You spare money - I time to find all places to remove unnecessary code in it. As You can that places know alread
Yep, been there, done that. The code is working in the M100, see first page. I prepared it for a GAMEBOY memory banking scheme. No code to access hub RAM instead of external RAM yet. You probably would do everything in the mem_page_1k entries anyway?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I see You have implemented some 8085 Instructions to.
Thanks.
As GAMEBOY have in that places some special instructions - It will be very simple to change them to that instructions.
BUT GAMEBOY need 3 bank's of memory - RAM/ROM and one special area for emulation of LCD memory. As that memory in This CPU have separate handler in Hardware and are physically separate area with their's separate address PIN's and if I remember correctly DATA lines to - BUT that I need look in theirs DATA Sheet to be sure.
Regards.
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha said...
As GAMEBOY have in that places some special instructions - It will be very simple to change them to that instructions.
You should just define e.g. GBCPU and replace the opcodes by their alternatives
#ifdef GBCPU
' Gameboy code for this instruction
i_whatever
....
#else
' 8080/8085 code for this instruction
i_rim
...
#endif
If you write the instructions and post them, I'll include them in the next release.
Sapieha said...
BUT GAMEBOY need 3 bank's of memory - RAM/ROM and one special area for emulation of LCD memory. As that memory in This CPU have separate handler in Hardware and are physically separate area with their's separate address PIN's and if I remember correctly DATA lines to - BUT that I need look in theirs DATA Sheet to be sure.
The code is prepared for that. You may have to add pointers for the RAM and the ROM range and then adjust them by the effective address ea. If e.g. RAM is from $4000-$5fff and you have a variable byte ram[noparse][[/noparse]$2000], or DAT ram byte 0[noparse][[/noparse]$2000], you would specify some q85 core variable ram_ptr := @ram - $4000 to adjust for the offset. Similar for ROM and the LCD range. For LCD you could just rename screen to lcd and use what's already there.
Or perhaps just look for the ranges, tell me and I'll adapt the code for you.
Thanks.
It take me some weeks before I can work on this - Have still some work on PCB's for Bill Henning.
But as fast I can I will give You all info/my own code that needs for that emulation.
As I think It is Yours code even if I modify it - we need have it like to be posible to all people to use it on all Hardware we can be possible make support to.
Regards
Christoffer J
Ps. Now I will study Yours code to learn me how it works - in time I think on Layouts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
If You are interested In attachment You have complete GameBoy CPU specification.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
If You are interested In attachment You have complete GameBoy CPU specification.
Regards
Christoffer J
Christoffer,
this memory map won't fit in a Propeller without external memory, no matter what you try:
16KB ROM bank 0
16KB switchable ROM bank
8KB video RAM
8KB internal RAM
= 48KB
Even if you would try to load the ROM sector wise from SD card while executing it, you would be in much trouble to fit the remaining bits of the memory map and code to emulate the GB. To me it looks like you can only do it with external RAM to hold the ROM image, ROM bank and internal RAM.
I agree. It is not at I will have entire Memory area on Propeller
BUT look on this Memory map - attached picture it is not 2x16 but only 1x16KB that must have FIXED address space.
Memory maping on this CPU is more complicated and I know it is not posible to run it entirely from HUB.
My goal is running ROM code from SPI type Flach/EEProms with BILL's VMCOG and only RAM area's from HUB.
Look on attached pic's on memory address space usage - It is only first 16KB that are Fixed Space next 16KB are bank switchable.
and that can be running entirely from external Flach IC's.
Regards
Ps. AND I know - I still must learn me much more on this CPU before I can find some solutions.
BUT - THANKS - starting with good base of CPU emulations help me much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Comments
Not problem for me to move it here.
But It was QZ80 code I was interested in as it is much faster - Give better performance for emulating GAMEBOY CPU.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
With striped CPU code it is maybe posible emulate entire GAMEBOY in only HUB memory.
As it not use entire 8080/8085 memory space.
Most code RUN in BANCK addresed memory with relatively small window to it.
On Black/white LCD display window is only 2 KB to
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Christoffer,
the difference isn't dramatic, but perhaps 10-20%. As I said before, I may rewrite the 8085 emulation based off of the new qz80 code. After all it's just ripping out lots of code and changing some flag register peculiarities and the interrupt code. I've done that with the current ya85 code and it should be just as easy with qz80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Hmm.. I'll add a #define for a Propeller board without external memory then. You will need to use a memory access map like I did in TRS80 to map the rd_byte and wr_byte addresses. I used a resolution of 1K pages for TRS80, because 1K is the smallest unit with different meaning in the address space. The screen memory there is 1K, as is the keyboard matrix. This indirection of course slows down every memory access by several instructions and an additional hub RAM access, but you can't get around this.
For the M100 it was sufficient to distinguish between 1st 32KB (ROM) and 2nd 32KB (RAM), because all I/O there is through ports, not memory mapped. All I had to do was to prevent writing to the 1st 32KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/10/2010 7:17:30 PM GMT
GAMEBOY mostly use Memory mapping in 2 KB units. NOT sure now if RAM/ROM has 2KB else 4/8 BUT-
One window for RAM one for ROM and one for Display.
Rom code bigger as one window On cartridge are addressed as Bank's by special decoder on cartridge.
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
With 2K banks you need 32 bytes (or perhaps words) for the rd_byte/wr_byte remapping. Just take a look at qz80 how it's done if TRS80 is defined. There is a dispatcher that discards 10 bits of memory address and jumps to the appropriate code to handle the read or write for the given address. As long as things don't get too complicated, all that code should (or rather must) fit in the cog.
I'll go and copy qz80 over to m100 and start stripping it rather than going to the pub today. That has the advantage to save me some money
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Very much Thanks.
You spare money - I time to find all places to remove unnecessary code in it. As You can that places know alread
Then we can look on special instructions that this CPU have.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Yep, been there, done that. The code is working in the M100, see first page. I prepared it for a GAMEBOY memory banking scheme. No code to access hub RAM instead of external RAM yet. You probably would do everything in the mem_page_1k entries anyway?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
That was very fast
Thanks
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I see You have implemented some 8085 Instructions to.
Thanks.
As GAMEBOY have in that places some special instructions - It will be very simple to change them to that instructions.
BUT GAMEBOY need 3 bank's of memory - RAM/ROM and one special area for emulation of LCD memory. As that memory in This CPU have separate handler in Hardware and are physically separate area with their's separate address PIN's and if I remember correctly DATA lines to - BUT that I need look in theirs DATA Sheet to be sure.
Regards.
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
You should just define e.g. GBCPU and replace the opcodes by their alternatives
#ifdef GBCPU ' Gameboy code for this instruction i_whatever .... #else ' 8080/8085 code for this instruction i_rim ... #endifIf you write the instructions and post them, I'll include them in the next release.
The code is prepared for that. You may have to add pointers for the RAM and the ROM range and then adjust them by the effective address ea. If e.g. RAM is from $4000-$5fff and you have a variable byte ram[noparse][[/noparse]$2000], or DAT ram byte 0[noparse][[/noparse]$2000], you would specify some q85 core variable ram_ptr := @ram - $4000 to adjust for the offset. Similar for ROM and the LCD range. For LCD you could just rename screen to lcd and use what's already there.
Or perhaps just look for the ranges, tell me and I'll adapt the code for you.
HTH
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/10/2010 11:34:14 PM GMT
Thanks.
It take me some weeks before I can work on this - Have still some work on PCB's for Bill Henning.
But as fast I can I will give You all info/my own code that needs for that emulation.
As I think It is Yours code even if I modify it - we need have it like to be posible to all people to use it on all Hardware we can be possible make support to.
Regards
Christoffer J
Ps. Now I will study Yours code to learn me how it works - in time I think on Layouts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
If You are interested In attachment You have complete GameBoy CPU specification.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Christoffer,
this memory map won't fit in a Propeller without external memory, no matter what you try:
16KB ROM bank 0
16KB switchable ROM bank
8KB video RAM
8KB internal RAM
= 48KB
Even if you would try to load the ROM sector wise from SD card while executing it, you would be in much trouble to fit the remaining bits of the memory map and code to emulate the GB. To me it looks like you can only do it with external RAM to hold the ROM image, ROM bank and internal RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I agree. It is not at I will have entire Memory area on Propeller
BUT look on this Memory map - attached picture it is not 2x16 but only 1x16KB that must have FIXED address space.
Memory maping on this CPU is more complicated and I know it is not posible to run it entirely from HUB.
My goal is running ROM code from SPI type Flach/EEProms with BILL's VMCOG and only RAM area's from HUB.
Look on attached pic's on memory address space usage - It is only first 16KB that are Fixed Space next 16KB are bank switchable.
and that can be running entirely from external Flach IC's.
Regards
Ps. AND I know - I still must learn me much more on this CPU before I can find some solutions.
BUT - THANKS - starting with good base of CPU emulations help me much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha