System card dreams....

[elmer]

This way you get an affordable card which works with either system and would offer expanded capability for translations.

Everything that you've said makes perfect sense ... you've just got to get that low 512KB of ROM switchable for RAM, and then (switchably) mirror the top 256KB of RAM into the regular SuperCD RAM location.

I really look forward to being able to buy one! 

Again, I apologize for the mistake. Guess you will have to fix mednafen after all

It looks like TailChao has already given you the capability that you want with the MCGenjin ROM, so I think that I still get to punt on the mednafen changes ... for the moment, at least. 

There are ways around it (burn a cd, and rip it to a cue/bin) but at this point, it's not worth the time and effort.

IMHO, someone either needs to fix HuC to produce .cue/.bin, or you guys need to finally let HuC rest-in-peace and get on the CC65 bandwagon.

That's a later part of the dream (to keep folks from pressing a bunch of cds and re-selling them). If the card could be made cheaply enough, the people who want to play translations could buy it (and would only have to do so once) for that purpose.

Please don't kid yourself ... Tobias (or whoever) will be able to go to exactly the same Chinese factory that makes your production-version carts and get them to make some for him.

If you don't get them made in China, then he'll just get them reverse-engineered in China.

Then he'll put a PCEWorks logo on it sell it as the "offical" cart for his Deluxe Edition boxsets ... and sell it for more money than you're asking ... and the crazy fools out there will buy it anyway.

If you're doing this ... do it to encourage more/easier translations, please don't make the mistake of thinking that it will have any effect on the people that re-sell translations.

[HailingTheThings]

*unzips*

I'm waiting.....

*unsheathes katana*

Hmph, you're almost not worth it...

*teleports behind you, cutting you in half*

heh...nothing personnel...kid...

*tips fedora*

Talk about not knowing how to read someone. Jeeesh, were s'posed to wet your lips and close your eyes. This is the greatest gift I can give.

[poponon]

Talk about not knowing how to read someone. Jeeesh, were s'posed to wet your lips and close your eyes. This is the greatest gift I can give.

[HailingTheThings]

Talk about not knowing how to read someone. Jeeesh, were s'posed to wet your lips and close your eyes. This is the greatest gift I can give.

I quit.

[Bonknuts]

Sorry, late to the party.

 So a few things..
 EX_MEM is useless, but a game might depend on it. There's also a 'register' in the $FFF4 of boot rom (fixed vector bank) that gives you the starting bank #num of the system card (either $80 or $68). I wouldn't change this either. The way I see it, is that you don't want to break any capability with existing games. If HuC relies on this, then that can be fixed/addressed. HuC would need a little bit of re-structuring for the starting bank address, but IIRC this is pretty easy to do (IIRC there are if/def for SCD and the value of the starting bank set to vale $XX).  For ASM, this is a non issue.

 For new dev, or even translations, checking for the extended ram would be a simple as writing a byte to each bank and reading it back (I did this to detect SGX even when the compatibility switch is set to PCE MODE).

 My personal opinion; if we're gonna make a new extended version of the SCD 3.0 card - let's do it right and make the ram on the card 512k (there's still 64k on the CD base unit, for a total of 576k). Translations can make use of the extra memory for script compression issues, hombrew could make use of it specifically because it's more memory, and hacks can make use of it for holding more data (Megaman 2 and other larger NES roms running on PCE could also make use of it) - etc.

 I'm aware of the palette loading bug, but I'm not really concerned with it. I'm not sure what status reg bug Old Man is talking about, but I do know the processor status register is always saved (the interrupt call does this automatically). As far as VDC status reg, I'm pretty it gets written to a ZP reg somewhere. If not though, you can put a ram bank in MPR slot #7 with those suck modifications - without changing the original (again, needs to be a boot routine but HuC can handle that).

 On a side not, some SCD games try to write to rom (bios). Gate of Thunder actually tries to change the value of $fff4, which is $68, to something else. I suspect that it was part of a development thing. Obviously the change doesn't take effect (real system or emulator).   

 I think someone mentioned something about some mirrored stuff, that I mentioned previously? The only thing that I can think off the top of my head, for mirrored stuff, is that the system card rom is actually 256k, but it's mirrored as a 512k image. I have no idea of any game, or the system card itself, relies on this.

 On a side note, have you guys ever tried to swap out the ram bank MPR to run a dual system? Pain in the arse because you also have to keep track of two 'stack' registers. The reason I bring this up, is because my nes2pce stuff have to have their own MPR 7 bank mapped and can't use the system card stuff, but for the CD hardware I have to switch over to that environment when I do such calls (play a CD track). It'd be really nice to have a documentation of how to directly handle CD hardware via the scsi-ish (it's not exact) command string and how the status regs are used, to avoid all of this.

 As far as homebrew/huc, I have a new CD read routine that I ripped from Seiya Monogatari that will increase the read speed by decent amount (122k/sec vs 90k/sec of the original). There are some #$ff areas in the original CD boot bank, that when copied over to a ram bank and re-mapped there, could be used to call such new routines. There are some nice LZSS decompression routines from that game as well (decompress with a small ring buffer directly to vram, etc). Stuff like this can be made standard lib fair, but without modifying the original rom (but more of a patch done via ram and remapped).

[TailChao]

EX_MEM is useless, but a game might depend on it. There's also a 'register' in the $FFF4 of boot rom (fixed vector bank) that gives you the starting bank #num of the system card (either $80 or $68). I wouldn't change this either. The way I see it, is that you don't want to break any capability with existing games. If HuC relies on this, then that can be fixed/addressed. HuC would need a little bit of re-structuring for the starting bank address, but IIRC this is pretty easy to do (IIRC there are if/def for SCD and the value of the starting bank set to vale $XX).  For ASM, this is a non issue.

I really wonder how the Duo is enabling and disabling its internal 192K of memory, then.
Do you have any ideas?

As for the $FFF4 value, there's actually a large amount of cruft in the Super System Card's bank 0 right after the $FF padding and before the vectors aside from this. For the dummy 512KB ROM + 512KB RAM System Card patch I put up earlier, I plowed over most of it and the handful of games I tested happily continued along their way with no issues.
Wonder if anything actually depends upon those either.

On a side not, some SCD games try to write to rom (bios). Gate of Thunder actually tries to change the value of $fff4, which is $68, to something else. I suspect that it was part of a development thing. Obviously the change doesn't take effect (real system or emulator).

Great, I was hoping NEC would have been a little more strict about this. But I guess I'll have to implement some lock registers now.

[Bonknuts]

I really wonder how the Duo is enabling and disabling its internal 192K of memory, then.
Do you have any ideas?

 Charles Macdonald told me that the hucard detection pin is what the Duo and SuperCDROM units use in order enable/disable the rom+192k so that a hucard might take the whole lower 1mb range for itself. Technically, you could have a card that enables and disables this on the fly. The arcade card duo version, AFAIK, maps only two things to open bus area. One of the open bus area is banks $40-43, so it doesn't even set the pull the hucard detection pin to ground (pretty sure how that's how it works, or pulls it up). The other area is $1ffa00-1ffaff range (open bus in the hardware bank). So it doesn't even bother asserting the hucard detection pin.

As for the $FFF4 value, there's actually a large amount of cruft in the Super System Card's bank 0 right after the $FF padding and before the vectors aside from this. For the dummy 512KB ROM + 512KB RAM System Card patch I put up earlier, I plowed over most of it and the handful of games I tested happily continued along their way with no issues.
Wonder if anything actually depends upon those either.

I was assuming games don't use it. What were you going to use it for? Does you mapper header go there?

[nodtveidt]

So ... HuC has built me a 900KB iso ... but the current version of Mednafen doesn't support physical CDs any more, so there's no point in mounting it ... and Mednafen refuses to run it from the command line, it wants cue&bin, not iso.

Any suggestions?

Just make a cuesheet that uses an iso file... like so:

Code: [Select]

FILE myawesomeiso.iso BINARY
  TRACK 01 MODE1/2048
    INDEX 01 00:00:00
I dunno if you need to add a pregap or postgap in there or not though... I personally always have a track 1 audio file and put the iso at track 2.

[Arkhan]

wait wait.

why doesn't mednafen support real CDs? lol

[TailChao]

Charles Macdonald told me that the hucard detection pin is what the Duo and SuperCDROM units use in order enable/disable the rom+192k so that a hucard might take the whole lower 1mb range for itself. Technically, you could have a card that enables and disables this on the fly. The arcade card duo version, AFAIK, maps only two things to open bus area. One of the open bus area is banks $40-43, so it doesn't even set the pull the hucard detection pin to ground (pretty sure how that's how it works, or pulls it up). The other area is $1ffa00-1ffaff range (open bus in the hardware bank). So it doesn't even bother asserting the hucard detection pin.

Ok good, that was my original guess.
The only other way would be some magic register read sequence and I'm not too worried about that.

 I was assuming games don't use it. What were you going to use it for? Does you mapper header go there?

Ends up I forgot how my own patch was written, I didn't actually change this value, so we're alright in this regard.

However, what I did nearby was the following:
*$FF0F becomes the new "native" region startup vector.
*$FFF0 becomes the new "swapped" startup vector.
*Additional startup code was added around both of these, in the latter (swapped) case I had to plow over some seemingly unused cruft before the vector table ($FFE0-$FFF3).
*The MCGenjin mapper header lives from $FFD0-$FFDF.


Ok, cool. It should be perfectly feasible to get a 512KB ROM + 1MB RAM dual-region cartridge working for both a Duo and TG16+CD with no issues and good System Card 3.0 compatibility.
I'll do some card + mapper specs and start a new topic after a few days of thought.

[shubibiman]

BTW, I sent an e-mail to Tobias :

"Hi,

> do you mean that the guies who translated the games
> will get royalties on this ?

we're talking.

Best
Tobias"

I'm pretty sure he's talking BS here. Can you confirm that it's the case ?

[elmer]

Just make a cuesheet that uses an iso file... like so:

Code: [Select]

FILE myawesomeiso.iso BINARY
  TRACK 01 MODE1/2048
    INDEX 01 00:00:00
I dunno if you need to add a pregap or postgap in there or not though... I personally always have a track 1 audio file and put the iso at track 2.

Thank you, that worked perfectly!

My bad for not remembering that I could do that ...  it's been many years since I had to edit a .cue file manually.  :oops:

[TheOldMan]

Update:

I haz a dream:  Someday Arkhan will tell me all of the Alantean boards are done, sold and shipped.

Check.

I haz a dream: Arkhan will total everything up, and we will have actually made a small profit...
  And it's enough money to develope the new system card....

Check. And almost.

I haz a dream: We order prototype boards and all the pieces...
  And I put them together without screwing things up...
  And they work...
  And the bios is reprogrammable, for future changes.

Check. There went my atlantean profits. And some extra $$
Sometimes. They're a pain.
Haven't finished complete testing, but it's looking good. Looks  like it needs a filter capacitor added, though.

YES!

I haz a dream: Bonknuts has time off from school, and decides to work on translations....
 And he finishes one using the new system card....
 And expands on MegaMan-CD as well.

He's working on it again So maybe....

I haz a dream: With the extra flash space, we start adding useful routines for translations and developement....

Covell has an ML monitor.
(If you see this chris, lets talk licensing....)

Of course, I also have a dream where everyone from the turbo game shows appear at my door to use the bathroom,
piss all over the shower, and my wife says "They're your friends. *You* clean it up....."

No, but the cats have learned a new trick. Guess what it is....

............................................................

No, I will NOT build you one. They are a royal pain-in-the-arse to build.
I already have people picked out to send them to, *as they are built and tested.*
(for free, but you have to be a developer. It's not much use to anyone else.)

No, even if I had a lot of them made, I wouldn't sell them. I'm not interested
in making $$. I'm interested in getting a -complete- free dev environment for
the pce set up - and brought up to date.

And I still have a lot to do on Sabre-Riders. That comes first.

With that said, the boards could be built for under $20, in lots of 50. All parts
included, At last check. They support ROM/RAM and are 'fixable' to support
ROM/ROM. Yes, an 8M bit game is on the to-do list. Eventually.

There is still a ton to do on the software side, though.

So, how long before someone decides to clone these?

[NightWolve]

Of course, I also have a dream where everyone from the turbo game shows appear at my door to use the bathroom,
piss all over the shower, and my wife says "They're your friends. *You* clean it up....."

No, but the cats have learned a new trick. Guess what it is....

............................................................

Laugh of the day!

[TheOldMan]

Laugh of the day!

Not on my end.