It is currently Mon Aug 21, 2017 10:50 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Thu Jul 27, 2017 12:36 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1860
Location: WhereverIparkIt, USA
na_th_an wrote:
but I can't really go any further as, as I said, my abilities are quite limited when it comes to providing emulator support.

To be clear, this statement has the caveat assumption that full emulator support is required for your development. If one were willing to test builds primarily on hardware that would be a way to get around full emulator support. I'm willing to provide development hardware kits at little to no cost. Lots of hardware testing will be necessary anyway especially early on while the mapper is still in 'beta' form. Typically emulator authors are more interested in supporting new mapper features when there is already a game that utilizes the mapper.

Another way around emulator support might be to test and develop on a similar mapper that's already supported by emus. But only utilize the mapper in a way that 'emulates' the target discrete mapper + CICOprocessor. That would simpify porting the mapper specific read/write routines over to the new mapper. FME7/Sunsoft5 might be a good choice especially if the emu supports CHR-RAM and the end target is UNROM + CICOprocessor. Even better if the emu supports >8KB CHR-RAM. FME7/Sunsoft5 can emulate UNROM banking, and has selectable mirroring, timer based IRQs, along with audio expansion.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Fri Jul 28, 2017 4:54 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 339
For something as simple as simulating the H/V mirroring switch in software, I can modify simple emulators such as Nester. Fceux should be easy to modify as well, as I understand the code I've studied (but I can't get it to compile no matter what I try - I'll try to address that issue later in the proper subforum, btw). It's just a behaviour simulation rather than true emulation. I would trap whatever you have to do from the game code to perform the switch, and order the emulator to act accordingly.

And I can always target, as you said, FME7 and perform the required changes to turn it into a UNROM+CICO.

I mean - I wouldn't need actual hardware to test while developing. I can always finish the software and send it to you once I have tested it in emulators, so there's no need for expensive overseas shipments :)

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Sat Jul 29, 2017 2:10 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1860
Location: WhereverIparkIt, USA
na_th_an wrote:
I mean - I wouldn't need actual hardware to test while developing. I can always finish the software and send it to you once I have tested it in emulators, so there's no need for expensive overseas shipments :)


I would actually prefer to put the hardware in your hands if you were taking the time to target the CICOprocessor. Would make the "build - test - report - rebuild" process much easier for both of us. The shipping costs are insignificant.

So I'll take this discussion as there being notable interest in my crazy CICOprocessor idea. I'm rather thankful I took the time to keep detailed notes in this thread about how I plan to execute everything. Being close to 2 months since I presented my nibble register interface I had pretty much forgot all the specifics on my idea..

I'll do my best to make progress on this effort sooner vice later and make progress reports in this thread.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Jul 31, 2017 6:57 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 339
Just the addition to H/V mirroring switching and the IRQ counter to simple discrete logic mappers is a plus. I'm sure many programmers target a more expensive ASIC board just for one of those features.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Mon Jul 31, 2017 10:44 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 496
Don't forget single screen.


Top
 Profile  
 
PostPosted: Mon Jul 31, 2017 11:00 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1860
Location: WhereverIparkIt, USA
calima wrote:
Don't forget single screen.


While single screen is possible, it would require the CICO to drive CIRAM A10 with one of it's pins directly. Which is incompatible with the tiny mux idea I plan to implement with software selectable H/V. Because of that, and the fact single screen AxROM style mirroring is a trival addition to any discrete mapper I don't think using the CICO for single screen is worthwhile.

It's not that one couldn't have single screen and CICO on the same board. You just can't have selectable H/V/single via software all at once without adding more logic chips.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Aug 16, 2017 1:57 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1860
Location: WhereverIparkIt, USA
Quick little update. I finally ditched SDCC (C compiler) for the STM8. I should have never bothered with C in the first place with the STM8. I thought I would take advantage of C for simplifing the initialization code and everything. And when I realized how there wasn't really an option to including asm files in a SDCC build I took the cheap way out and wrote the entire CIC operations with inline assembly. The inline assembly is pretty annoying to work with but I made it work.

I just migrated everything over to pure assembly and have been using naken_asm which has been great. I optimized everything in the process and became aware just how poor SDCC was.. My seed initialization routine ended up compiling into a horrendous mess. Hand writing that ram init routine alone cut my code by about half.

In the end I went from ~2.5KB to just over 1KB with my synchronous NES implementation by migrating init code from C to assembly. There's still room for more optimizations that would easily get me well under 1KB. When I move on to my asynchronous implementation, I expect the code to shrink by a fair amount as a decent number of timing NOP's will be removed. But some extra code will be needed to handle the timer operations too.

So in the end I'm expecting the actual CIC code to consume 1KB or less of the 8KB available on the STM8. Leaves a pretty decent program flash budget for all these potential features.

Starting to get a rough idea on how I plan to manage getting by with a 8bit TIM4 alone to handle the CIC timing. I'm expect that running without a prescaler will be helpful/necessary for more precise timing. So that will require software to count rollovers, but that code can be mid-low priority so I think it'll work okay.

But for now I've got to focus on implementing at getting a synchronous SNES CIC up and running. Once that's done, I'll start chipping away at an asynchronous NES CIC and some proof of concept with the nibble registers for adding features!

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], tepples and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group