Messages

[Localizations, Games, Apps, Docs / Re: Six-Button Controllers through a TurboTap]

The above facts that you illustrated with the GIF is sadly the reason that I discovered my RS232/UART monitor PCEmon can't be used with a TurboTap: there's no way to select one of the 5 ports, and then send serial data to it through the output lines. 

You might actually be able to send data out, it's just not convenient and you could only use the first port on the tap. You're using Output 0 (SEL) for TxD and Input 3 ("L / RUN") for RxD, right?

The rising edge of CLR will always reset SEL1 to a high state. If you keep CLR high instead of lowering it like the documents say - then toggle SEL, SEL1 will toggle but the tap will never advance to the next controller port. So if you program the transmit routine to abuse this it should work.

Getting data in or doing full duplex would be a bigger problem.

[Localizations, Games, Apps, Docs / Re: Six-Button Controllers through a TurboTap]

I'm here for the turbotap gifs
(and this is interesting - is it that it's just not powering the other slots? does it take more power to get a 6 button controller going vs a 2? feels like that'd be pretty negligible)

All five controllers are always powered through the tap (and yes, the difference in power draw between three and six button controllers should be negligible). The important thing is that only one controller is selected at a time.

The tap could have been implemented a few ways in hardware to get the same read results (i.e. SEL could be passed to all controllers directly rather than the fancy counting sequence in the gif). But I want to make a knockoff to use FEKA controllers so the specifics are helpful.

[Localizations, Games, Apps, Docs / Re: Six-Button Controllers through a TurboTap]

In particular,SF2 doesn't fully read the inputs from ports 3-5. IIRC port 3 is partially read (I think the RUN button is checked?), but the 4 and 5 are basically unread. Seems like the behaviour is driven by the game.

Good to know, thanks!

It makes sense that SF2 is using a simplified read routine like that. If it only needs support for two players there's no point in spending time reading in the extra data.

[Localizations, Games, Apps, Docs / Re: Six-Button Controllers through a TurboTap]

Guess I'll answer my own question.



Looks like my guess above was correct. Below is some more info about the tap :

Code Select Expand

    Rising Edge of CLR resets the TurboTap and selects Controller 1.
          |
          V
          ___                                                  ___
CLR  ____/  \_________________________________________________/  \___ ...
      ____________    ___    ___    ___    ___    _________________
SEL              \___/  \___/  \___/  \___/  \___/                  ...

                      ^
                      |
    If CLR is still high on the Rising Edge of SEL, Controller 1 will remain
    selected and SEL1 will just toggle. So the Rising Edge of CLR resets the
    tap and the first controller will remain selected until it lowers.

      ____            _________________________________________
CLR1      \___________/                                        \_______ ...
      ____________    _________________________________________________
SEL1              \___/                                                  ...
      ________________        _________________________________________
CLR2                  \_______/                                          ...
      ____________________    _________________________________________
SEL2                      \___/                                          ...
      ________________________        _________________________________
CLR3                          \_______/                                  ...
      ____________________________    _________________________________
SEL3                              \___/                                  ...
      ________________________________        _________________________
CLR4                                  \_______/                          ...
      ____________________________________    _________________________
SEL4                                      \___/                          ...
      ________________________________________        _________________
CLR5                                          \_______/                  ...
      ____________________________________________    _________________
SEL5                                              \___/                  ...


After ten edges on SEL, the tap will deselect all controllers. I've seen claims that repeatedly toggling SEL after this will either cause the tap to wrap around or just stop reading and output "0000" - I've gotten both behaviors to occur and can't find a pattern for either. So my guess is that the intended behavior was the tap should stop reading after ten toggles of SEL but this doesn't work right so don't depend upon it in any software.

[Localizations, Games, Apps, Docs / Six-Button Controllers through a TurboTap]

I'm trying to read the state of multiple six-button controllers through a TurboTap. Unfortunately I don't own any of these controllers nor could find any information on how this is supposed to work.


Based upon this six button schematic, and these TurboTap notes I'm guessing you'd do the following :

1) Start with SEL high and CLR low.
2) Raise and lower CLR to reset the turbotap.
3) Read in all five controllers' data by toggling SEL ten times...
3a) IFF the controllers' data are all low when SEL is high, THEN this is a six button controller. We can assume the data pulled in when SEL is low will be the extra buttons' states.
3b) IFF the controllers' data were all low when SEL was high previously - but aren't now, THEN this is a six button controller and we're pulling in the "default" button set.
3b) IFF the controllers' data are never all low when sel is high, THEN this is definitely a two button controller.
4) Repeat steps 2-3 a second time to identify and fetch the other half of the data for any six button controllers.

Any help would be appreciated.

Edit : Made signal names a little more clear.

[Console Repair/Mod Center / Re: Guide - Built-In Game for the TurboGrafx]

Is it possible this was going to be for a built in System card?

I don't think so, at least if the data were only going to be stored in IC107. Enough of the address pins are grounded that a 27C1000 compatible ROM would only be able to contain 1KB of data.

[Console Repair/Mod Center / Re: Guide - Built-In Game for the TurboGrafx]

Magical Chase gouging is never a joke. The first time I saw this done to a TG-16, it was an ebay listing someone posted here. It was sold as a 'rare" one of a kind unit with Magical Chase built-in.

That's ridiculous. I do remember seeing another TurboGrafx with this modification though, so maybe it was that one.

I'd love to have one made with a homebrew rom like Atlantean and dye/paint it blue to match. Maybe change the logo to Aetherbutt-16 or something.

That could be pretty nice. There's been enough decorated consoles given away in Kickstarters and such that don't have the game they're promoting built-in.

This is amazing stuff. I wish I still had my PAL Turbografx to check for the empty pads.

The PAL board photos I've seen just have a big ground plane where the pads were, but that doesn't mean they're all that way.

P.S. I like your wood.

At first I thought you meant the television. But yeah, the floor is nice too.

[Console Repair/Mod Center / Re: Guide - Built-In Game for the TurboGrafx]

So are those empty spots only on the TG-16 (and maybe PAL TG) or are they on all the PCEs, Duos, Shuttles, etc. too?

As far as I know they're only in NTSC TurboGrafen.

[Console Repair/Mod Center / Re: Guide - Built-In Game for the TurboGrafx]

Heh, that's pretty neat.  Looks like a relatively clean install and I'm surprised you can fit all those kangaroos in.

I was considering putting a System Card 2.0 in there so it'd be just like owning a Duo except worse, but the kangaroos are a way better resident. Best option is probably to install Magical Chase and flip the thing on eBay so I can buy a few cars.

Anyway, TurboGrafx is all put back together.

No game inserted gives you Kangaroo Mans '94.


Putting a card in will run that instead.


CD Stupid Cards and rare sharpie-edition games are still fine.

[Console Repair/Mod Center / Guide - Built-In Game for the TurboGrafx]

I was doing some rework on my TurboGrafx and decided to poke around at the unpopulated chip pads for IC107 and IC108 near the HuCard slot.

I've seen literature claiming these may have been intended for a built-in game. But after tracing back the pinout of both chips it looks more like IC107 was just supposed to contain a small instruction screen which is displayed when you start the console without a card (like the Master System). IC108 controls the mapping, and probably was just supposed to obfuscate the address line mapping of IC107 to make it more difficult to install stolen software.

But that's just a guess.

Anyway, with some work we can install our own built-in game up to 8 MEGA POWER in size. What we're going to do is adapt the original socket to hold a 27C801 compatible chip and add a small circuit to activate this ROM if and only if a HuCard isn't inserted. I'd rate this at moderate difficulty if you'd like to try, i.e. you should have some basic electronics knowledge and steady hands.

Let's do some soldering.

Here's the pinout for IC107 :

Code Select Expand

                IC107
              _____ _____
        VCC | 1  v  32 | VCC
        OEn | 2      31 | R139 *
        GND | 3      30 | GND
        GND | 4      29 | GND
 ** IC108,18 | 5  2  28 | GND
 ** IC108,19 | 6  3  27 | IC108,17 **
 ** IC108,20 | 7  C  26 | IC108,16 **
 ** IC108,21 | 8  1  25 | GND
 ** IC108,22 | 9  0  24 | GND
          A2 | 10  0  23 | GND
          A1 | 11  0  22 | IC108,15 **
          A0 | 12  E  21 | D7
          D0 | 13    20 | D6
          D1 | 14    19 | D5
          D2 | 15    18 | D4
        GND | 16    17 | D3
            |___________|

  * R139 isn't populated, so this is NC'd.
    Looks like it was just supposed to be a pullup.

 ** IC108 isn't populated, so these are NC'd.


We need to modify it like this :

Code Select Expand

                                        IC107
                                      _____ _____
              *** A19 (HuCard Pin 3) | 1  v  32 | VCC
              *** A16 (HuCard Pin 4) | 2      31 | A18 (HuCard Pin 33)
              *** A15 (HuCard Pin 5) | 3      30 | A17 (HuCard Pin 32) ***
              *** A12 (HuCard Pin 6) | 4      29 | A14 (HuCard Pin 31) ***
  **** A7 (HuCard Pin 7) <- IC108,18 | 5      28 | A13 (HuCard Pin 30) ***
  **** A6 (HuCard Pin 8) <- IC108,19 | 6  2  27 | IC108,17 -> A8 (HuCard Pin 29)
  **** A5 (HuCard Pin 9) <- IC108,20 | 7  7  26 | IC108,16 -> A9 (HuCard Pin 28)
 **** A4 (HuCard Pin 10) <- IC108,21 | 8  C  25 | A11 (HuCard Pin 27) ***
 **** A3 (HuCard Pin 11) <- IC108,22 | 9  8  24 | OEn (HuCard Pin 26) ***
                                  A2 | 10  0  23 | A10 (HuCard Pin 25) ***
                                  A1 | 11  1  22 | IC108,15 -> GAME_CSn
                                  A0 | 12    21 | D7
                                  D0 | 13    20 | D6
                                  D1 | 14    19 | D5
                                  D2 | 15    18 | D4
                                GND | 16    17 | D3
                                    |___________|

  *** Original trace must be cut.

 **** You can also just reconnect these address pins on IC108's pad.
      A7 == IC108,18 -> IC108,64
      A6 == IC108,19 -> IC108,63
      A5 == IC108,20 -> IC108,62
      A4 == IC108,21 -> IC108,61
      A3 == IC108,22 -> IC108,60

The circuit to enable the internal game (GAME_CSn) when a card isn't inserted can be two NAND gates using A20 (HuCard Pin 24) and CARDn (HuCard Pin 1).

Code Select Expand

GAME_CSn = !(!(A20 & A20) & CARDn)

This can be implemented with a single 74LS00. Below are two photos of my board to give an idea of how much stuff you'll have to add.




Keep in mind some of the patch wires here are for different repairs or from when I was reverse engineering stuff. Basically, doing this won't make such a huge mess.

[Console Repair/Mod Center / Re: PC Engine / TurboGrafx 16 CDRom ?]

ASIDE: Do you think hardcore NEC PC fans* would shake their heads in disapproval for sacrificing CD-ROM drives for a mere PCE/TG-16 console?

Probably not, they're just 1x SCSI drives and there's plenty of (better) alternatives in that category.

[Console Repair/Mod Center / Re: PC Engine / TurboGrafx 16 CDRom ?]

Nice, you got it working 

By the way, any idea how to re-program D78C14GF ( if already programmed ) ?  eg, what kind of equiment?

The datasheet mentions a custom programmer from NEC, not sure if anything else supports it. The D78C14s in these drives are likely OTP or mask rom so unfortunately there's no real easy way to reprogram them.

[Console Repair/Mod Center / Re: PC Engine / TurboGrafx 16 CDRom ?]

I wonder how-on-earth that was discovered. 

I'm not sure if anyone else has tried the swap, but I only found out because the normal TurboGrafx CD-ROM drives were too expensive but the CDR-35Ds were just cheap enough.

When I got my TurboGrafx it came with the CD booster but no drive or system card and both of those were out of my price range. Almost ten years later I did find a smashed up drive at a flea market but the chips were intact. Since the drives looked so similar I guessed there was only a small change inside and after ordering and disassembling a CDR-35D the boards looked identical and the D78C14GF was suspect since it's a microcontroller with mask rom.

So I swapped the chips and this is how I've been playing CD-ROM games for the past seven years.

[Console Repair/Mod Center / Re: PC Engine / TurboGrafx 16 CDRom ?]

It is actually possible to use a CDR-35D-01 with a TurboGrafx or PC-Engine, but it requires swapping the drive controller IC (marked D78C14GF) since the drives use different firmware. It's also possible to get an unprogrammed D78C14GF and program it but either way this requires removing a QFP from the board and can be a little difficult without the proper equipment.

[Localizations, Games, Apps, Docs / Re: Updated PCE development information page?]

* PC Engine GT Com Cable pinout and protocol. I've found zero info about this (other than that it has standard 3.5 mm TRS stereo cable plugs).

It's better not to know.
In short, it's all bitbanged through CLR and SEL unless there's some piece of hardware I don't know about. Kinda lazy.

[General Gaming / Re: Wataroo - A New SuperVision Emulator]

Understandable, but Zaku sure looks better than most everything on the Lynx, and better than a lot of PCE homebrew, so... well, I'd be happy to have it!

I second and third the sentiment.

Seriously.

Haha, thanks. I appreciate it  .
Now let's see if I can ship something better  .

Again, I would really like to do a big project on the PC-Engine. I just want to first make sure it's affordable and will be interesting because the game is unique rather than just because it's running on something old.


Edit - Not that any of this has anything to do with the Watara SuperVision! Better get back to discussing classics like "Matta Blatta," "Witty Cat," and "Cave Wonders!"

[Off-Topic / Re: Northeast meetup - Funspot/ACAM in Laconia, NH]

Not sure I can participate in a meetup but I highly recommend this place if anyone hasn't been there before.

My friends and I drive out there at least once a year to play Space Harrier and Marble Madness. They take good care of their machines.

[General Gaming / Re: Wataroo - A New SuperVision Emulator]

I admit that I am curious about SuperVision.

It's kind of interesting if you like off-brand stuff. But the manufacturing is very poor and the software quality is very worse. If I wasn't doing reverse engineering on the unit I wouldn't have paid money for any of it.

That said, there are a few good ideas here and there like the bendable screen mount and Audio DMA. The cover art for most of the games is also wonderfully bad. It's a great juxtaposition of "this is kind of neat" and "wait, why did they do this?"

Heh, pretty cool.  Although not a 'fan' of the SuperVision, I did own Chimera, and found a 27512 EPROM inside & dumped it in 2000 or so.  Good memories, shame it was so crappy otherwise.

Yeah, most cartridges seem to just have either a glob or EPROM haphazardly stuffed in there. I can't imagine what the assembly line for this hardware was like.

I'm glad you made this! Also... what are the odds you'll ever port Zaku to PCE?

Very low. I think the PC-Engine already has many good shmups and I did not do a good enough job while designing Zaku to distinguish it from many of the games I was imitating.

I would like to work on a PC-Engine title in the future, but right now I am working full time on an action-puzzle hybrid for both the Atari 7800 and Windows. Whether or not I do another serious project for old hardware very much depends upon how the rest of this game's development goes.

Tinkering in my spare time though, is incurable 

[General Gaming / Wataroo - A New SuperVision Emulator]

I've decided to publicly release the Watara SuperVision emulator I've had sitting around. Now you can learn about another 65c02 cousin to the PC-Engine, or just unpack it then throw the emulator in the trash (just like a real SuperVision).


It also includes a little hardware test program to help fix broken units and confirm the weird behavior of the scrolling registers.

Only the STANDARD mapper is supported right now. I was hoping to get MAGNUM emulated, but I don't own that hardware variant nor a copy of "Journey to the West." The price on this garbage actually went up on eBay, and I'm not interested in paying it nor inviting more ancient hardware into my apartment.

Note that when loading ROMs the emulator will default to using the *.cdf extension which is inherited from another emulator I haven't released yet. Raw binaries are supported, just not the default option in the combo box. Of course, this is all in the help file.


Aside from the lack of TV-Link emulation this is probably the most accurate SuperVision emulator (as of writing). If you're going to huff paint thinner, you may as well do it correctly.

However, the port of Chimera B.I.T.S. did is actually quite well made.

Edit - Of course if anyone wants to donate SuperVision hardware to emulate that is totally cool.

[Localizations, Games, Apps, Docs / Re: PCE PCM]

C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys!   

Well, on 2nd look, I think that we'd actually need a YMF289B OPL3 FM chip + YAC513 DAC, in order to meet the fast memory access timings of the PCE, and those cost a little bit more ... approx $6 per pair. 

You also need an oscillator and will only get mono audio anyway.

Those great 5V ARM microcontrollers from Cypress you brought up over a year ago are still the best solution here. Analog out is included, and if you add some sort of bidirectional comms in a mapper you can use it as a Cypress FX.

I ended up going with the FM3 family for my current project (specifically the MB9BF524K) and ported over my Windows softsynth without any huge issues. But this is a full music player, and I think in the case of the PCE it would be more useful to just complement what's already in the box.

BTW ... I absolutely *love* the sound of Yamaha's 4-operator FM synths. 

Fantastic sound, whole OPN family is really cool.

Although if you're just looking for chips to mess with the YM2608 is pretty well rounded compared to the others. I did start building a HuCard with an MC-Genjin + YM2612 on it a few years ago but never finished it for the sourcing reasons above.

RPGs with SNES sampler style string leads on the PCE? Not interested? I am.

If it works with the style of the game, why not?

[Localizations, Games, Apps, Docs / Re: PCE PCM]

I just want an expansion of the PCE sound. I don't want to necessarily replace the PCE sound, but something that works with it. 8bit mixing allows some bass to the PCE (thump/bump), and software samplebased synth gives it much more range with bass style instruments - as well as others (imagine using that orch hit in batman, but at any note/octave).

The AUDIO_IN pin is ready whenever you are.

[Localizations, Games, Apps, Docs / Re: Huzak - Yet another music driver]

At the end of the day, it's not the tool that makes the song, it's the musician.

This is a fairly important point which I don't see addressed much.

Creating a game soundtrack is already a significant time investment, making it within the limitations of old hardware can be worse. Sometimes it can be easier to split the job into composition and sound programming with some back and forth between both parties.

Really - it's not whether trackers, sound languages, or whatever driver is best that matters. Just use what works best for your group. You're all lucky enough to be working with a console with a CD upgrade and can just toss all these dumb requirements out the window anyway.

[Localizations, Games, Apps, Docs / Re: Huzak - Yet another music driver]

It's a decent start ... but as you know yourself, it's all really about the tools that surround the driver so that the musician can actually create a good tune and get it in exported in a format that the driver can use.

Oh ... then there's getting the driver's effects-processing to reasonably-match the sound that the musician hears in the package that they use to create the tune.   

Yeah, although I do think you have the right idea by just going straight for Deflemask support. It's a good tool and the time saved from the composer's end will likely justify the investment.

Funny sound languages are outdated and I'm going to eventually have to part with my own (or hide it under several carpets).

Ahhhh ... ELP, good stuff! I'm really more of a Tull fan, though. 

Nothing wrong with that 

[Localizations, Games, Apps, Docs / Re: Huzak - Yet another music driver]

Nice work so far, good to see more sound tools.

Different strokes for different folks.  But anyway, I think the PCE is not so well suited for arpeggios as it is detuned pairs of channels.  Games that do that usually sound fantastic.

Totally, and it has the channel count to pull this off well.

Oh ... and prog-rock and all of those other things that influenced the generation of English computer-game musicians that you have fond memories for.

Welcome back my friends to the show that never ends

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

Another question, do you think the Hucard format by himself, was a big limitating factor for larger ROMS than a classic one, like on MD/snes ??

Honestly, no. Most HuCards are chip-on-board, which is cheaper in volume and when you have the right manufacturing setup. Using larger Mask ROMs isn't a big deal as the dies are still much smaller than the card dimensions. I mean really large volume, though. Hundreds of thousands minimum.

I think the biggest factor was the prevalence of the CD-ROM format on the platform.

Again though, I didn't work for Hudson or NEC. So I can't definitively speak for what they were or were not trying to do.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

Ah, is not as easy as i though then .. 
Do you think that even nowadays,it's not affordable ??

I wouldn't phrase it as "not affordable" to have a huge NOR Flash, but rather it's good to be aware of what restrictions it would impose on the manufacturing end so you can consider alternatives.

Generally, once you get over 512KB - 1MB, 3.3V NOR Flash is much cheaper. Once you get over 2MB it's nearly impossible to find large quantities of 5V tolerant parts, and what you can find is usually new-old-stock. So you'd need level shifters and a regulator on the cartridge.

If you're adding a mapper, you need either a CPLD or several 74xx components.

Sometimes it's cheaper to add more RAM to the cartridge and depack data to it rather than using a larger ROM and more complex mapper. I ran into this with the game I'm working on now.

Once you get into several megabytes of data, it might be best to use a combination of NOR Flash + RAM + SPI Flash + Mapper + Level Shifters.


Basically it is good practice to think ahead for what parts are available and what are not. Sometimes the "best" option is completely different now than what you would do 25 years ago.

Edit : But again, the PCE is quite competent on its own, so there's that.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

Of course like bonk said with a SF2 mapper and a 32/64 Mb hucard it's easily dooable,and with a good PCM driver and clean samples even at 7khz you can do an impressive PCM quality for a 8 bit system,better than MD @14/16 khz ones(with stef's driver), due to hardware .

You still have to be a little careful with ROM size since once you pass 2MB it gets more difficult to find affordable 5V components (4MB, 8MB+ NOR Flashes are increasingly uncommon). There are workarounds of course, but nothing is ever "for free."

This reminds me of the special sound chip shoved into Pitfall II on the Atari 2600. Even back then, people were doing new things to overcome the inherent limitations of the system they were working with.

It's even easier to do stuff like this nowadays. Microcontrollers are cheap, and Cypress has some that are both equipped with analog outputs and 5V tolerance.

[Localizations, Games, Apps, Docs / Re: HuSound]

How do you add arpeggios, vibrato, tremolo, note-transposition, and *musical* sweeps and slides to the tracks in HuSound (the hard-coded add-a-frequency-step isn't *musical*, the step size needs to depend upon the note that was played)?

I usually accomplish this by making two or three instruments with manually tuned hard steps to cover a wider frequency range, kind of like how you'd have multiple source instrument samples at different octaves for a sampler.

This is one thing I'm not really happy about, but usually one instrument won't wander around a huge octave range anyway (and to be honest many games don't even bother with this). If that kind of precision is needed you could probably build it into the SASS compiler side to autogenerate more instruments or shove some tables into ROM and let the driver deal with it.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

Either way, none of my music drivers have universal appeal. They were all tailored with very specific goals in mind.

This is probably true of most sound drivers and their associated toolchains for dinosaur hardware.
Which is not a bad thing, really. I don't think there should be so much paranoia related to writing audio tools.

Whatever works best for your needs and allows the product to ship is what should be used.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

It'd be great if that SASS thing from TailChao had a midi--->SASS conversion.

It has one here, which is also under zlib.

I'd like to write a Win32 tracker eventually with export support for the current SASS targets (BupBoop, HuSound, and HandyMusic), and HuSound needs a rewrite but this is all for way later.

[Localizations, Games, Apps, Docs / Re: Xanadu II Translation Development Blog]

It's finally done, and I thought that it might be good to explain the technique used, since it's not one that's been commonly seen since the 4th-generation development days, and someone might want to use it in another translation, or a homebrew game.

Thanks for doing this, it's very appreciated.

I like the drop shadow. It subtle but effective. Nice.

It'll probably look very clear over composite, too.

[Localizations, Games, Apps, Docs / Re: CD Stupid Card 4.0]

I'm definitely interested if one of these is still available.

Thanks for the extra info, steve. I would volunteer my card up for testing if it wasnt buried in storage

Unfortunately, I think all the cards are accounted for unless I can get a few of the botched ones reworked (which won't be soon).

While I'd love to get started on designing a CD-Stupid 5.0 with arcade card compatibility, the biggest obstacle isn't ordering an arcade card but rather engineering time. I've made obligations to ship a game next year and that's already tight. Although afterwards I'd like to take a break or a month or two and maybe then there will be a few opportunities for hardware mischief.

In any case, my notes are available if anyone else would like to try 

[Localizations, Games, Apps, Docs / Re: Turbo Everdrive 2.4]

I'm just having trouble seeing where a 512KB/512KB System Card fits in, or would actually be cheap enough to sell to folks.

Of course, the elephant in the room from when we discussed this over a year ago is still loitering by the water fountain -

Duplicating NEC / Hudson's firmware is a big legal grey area. The TED v2 puts that responsibility on the user and the CD Stupid Cards just happened to have the bits on flash arrange themselves in a somewhat convenient order.

[Localizations, Games, Apps, Docs / Re: Is this an alternative to C?]

Assuming the cost is low, part of the problem is modifying an emulator to run an ARM core. It's possible (I have a build of mednafen that has a 68k core running as accessible via ports on the PCE hardware bank).

I was wondering why that was in the Mednafen source for years. Good to know.


Also, I didn't mean emulate the whole ARM core on the PC. Ideally you'd define a simple messaging system between the HuC6280 and the ARM (or whatever coprocessor) on the cartridge. Then you can have all the coprocessor functionality compiled natively on the PC.

If the coprocessor is running all your game logic, you technically don't have to emulate the full PC-Engine hardware at all, just what it was supposed to do (get inputs, display this, play this noise).

For example, I have all the game logic running natively on the 6502 in the 7800. There is an ARM in the cartridge which runs a softsynth and responds to simple messages like PLAY, STOP, ATTEN, PAUSE, RESUME, and RESET. When running the game on Windows, the softsynth is native and the game is emulated. You could just as easily do the opposite.

Edit :

I'm comfortable with assembly, so I'm good without it. But I can see it being attractive to some.  I also code for the PCE because of the challenge, and that games really didn't push its limits. That might not be the motivator for all, though.

I agree, and yes - there is always more that can be done with any hardware.

Unfortunately, it can't be done for free.

[Localizations, Games, Apps, Docs / Re: Is this an alternative to C?]

Hahaha ... you're right, that's certainly one option. 

It may even be a sensible option.

But it's not the intellectually-challenging option. It's not "fun" (to me, at least).

It may not seem intellectually challenging at first, but once you start thinking about dedicating all the HuC6280's time to banging raster effects while the ARM does your game logic it gets more interesting.

I totally understand your point though, and wouldn't actually go with this option for this particular console.

So did Sega with the Mega-CD and the 32x. 

They certainly did, and were probably inspired by a fairly large spill of chex mix.

If you just want to write a "game", and don't really care what it runs on, then there are plenty of options out there ... like Unity.

Oh, and I, personally, have no interest in doing a PC game. Been there, done that, have the polo shirt.

It's interesting (to me, at least) to try to push the old hardware and see what can be done.

They're certainly not bad options either. But my point in bringing up a PC version is so that people who don't own the original hardware can play the game easily. I ended up having to write an emulator for a current project since the licensing (and codebase) for existing ones were so chaotic. Although that was fun.

The best new-game-for-an-old-thing I've seen that's actually shipped is still Fantasy Zone II DX. Aside from being a stellar product for the System-16, it was also available day one for the PS2 - in 2008. I think we can do better nearly a decade later.

There are so many compiler-compiler tools out there these days, that just reading in a program in C-style-assembler and then transforming it into standard-assembler, is a pretty simple project.

Then I could get to play with the CoCo/R parser-generator again. It's so much nicer that lex/yacc, and it already has a complete ANSI C grammar written for it. Just add the symbol table, shake it all up, put it into the oven for half-an-hour, and it's done. How tough could it be? (Famous last words!  )

I think you would be able to manage with just a good macro assembler and well developed support libraries  .

[Localizations, Games, Apps, Docs / Re: Is this an alternative to C?]

In response to the original topic -

Is the goal is to just make development faster and simpler, but still have everything run on the PC-Engine?

Why not just run everything on a microcontroller and use the console for video, audio, and input? That way you can just write everything in C (or C++) on a PC with some little emulated bits, then shove it on a sub $5 ARM. I can almost guarantee this is "cheaper" since the time investment will be lower than adding HuC6280 support to another compiler, and you get a PC version of the game for similarly low effort.

The fact that the performance will likely be better is another plus.
Nintendo did it back in the day, and there's no shame in doing it now to ship a better product.

[Localizations, Games, Apps, Docs / Re: HuC questions.]

The current method, where you can allocate large local variables on the stack, but all accesses use "(sp),y" ... makes expression-evaluation and parameter-passing incredibly slow, basically forcing you to make absolutely everything a "static" and avoid expressions as much as possible.

Giving up a chunk of the ZeroPage for a (zp,X) software stack is not a huge loss. I think that's livable considering the speed improvements over (zp),Y or (zp).

But I think the real question is what people want to use C for on this platform, and how they want to write it.

Making everything static is really the only way to get good performance on the 65x family outside of the 65816, especially for your object system - statically allocated arrays of individual attributes.

Right when you bring any requirement for address + displacement into the equation, performance drops on the 6502. The problem is that many of C's great conveniences depend upon it. If you're stuck writing restricted C in order to cater to the shortcomings of the architecture then (personally) I don't see the benefit over just writing the assembly.

A compiler that knows to split a statically allocated array of structs into a struct of arrays, then further split each element larger than a byte into individual byte arrays, then access everything that way would be pretty cool (maybe something does this already?). I think this is really the biggest performance gain area - but it's also so contrary to C in general.

[Localizations, Games, Apps, Docs / Re: Dragon Warrior for PCE]

The poor old 6809 never got much of a life to shine as an 8-bit CPU (or as a 16-bit CPU if you think like a SNES fanboy), because the introduction of the 68000 one year later in 1979 totally eclipsed it.

It still had a pretty good run. Many of the architecture's trademarks were built upon in the 6811 and 6812 which were extremely popular residents in consumer electronics.

Even the dumb height adjustable desks at my last job used 6812s to control their motors.

But yeah, great design. Good set of addressing modes (indirect + offset, finally) and math instructions. What the 65816 should have been.

Edit :

Apple II was for rich cunts, or douchebags.

Or people who just wanted functional disk drives.

[Localizations, Games, Apps, Docs / Re: Look Up Tables in HuC?]

The first course is Java, but from what I've seen of the course descriptions, C++ is definitely required for some classes. I've read that most system level code is still C (instead of C++), so I'm assuming that'll be for some upper division classes as well (OS, compiler, etc).

Java -> C++ -> C -> Assembly is a fairly common CS timeline, with the last two mostly optional depending upon focus.

Why in the fuck would Computer Science be an art degree.

Colleges haven't really settled on a consistent way to handle "math lite" versions of degrees in science and technology fields. The other popular way is just to add "tech" to the end of the major name (i.e. Electrical Engineering Tech), which is what my college did.

The pitch is that you'll focus on "what's important" - just programming or just designing hardware or whatever. The catch is employers see you did a degree on easy mode, which may or may not work out.

I had originally started ideas for Insanity on the C64 in BASIC/ASM using the goofy programmer reference guide...

That was a pretty good book.

[Localizations, Games, Apps, Docs / Re: CD Stupid Card 4.0]

Ah, thanks for the info. The reason I ask is because even if arcade card pro support costs more to implement, it would be a better alternative than buying a real one. Mostly because for the money, your card would literally be the last one you will ever need. I really don't relish the idea of paying $100 something for a card that only works for a few games (even if they are good). In addition to the fact that IFU-30 owners have no choice except to get a pro card.

I totally understand.

After having some time to think about it - getting an Arcade Card compatible piece of hardware below the $100 range is absolutely feasible. It really shouldn't cost much more than the CD Stupid Card (for the components anyway). But in order to have everything fit in a HuCard sized space and get a reasonably featured CPLD, we need to drop down to 3.3V components with some level shifters. Then use BGA or other small footprints for everything else. The former (level shifters) aren't a huge issue, but I'm not experienced enough with BGA layout and assembly right now to tackle this.

[Localizations, Games, Apps, Docs / Re: CD Stupid Card 4.0]

What do you recommend to do for a full function test?

At minimum, the card should be able to start up and run software. The patched BIOS has to go through enough during initialization that it will hit most features.

If you'd like to be thorough (and have a chip programmer), you can reprogram the flash with the hardware test program. This is what I used to verify cards before sending them out to everyone. Note that it doesn't have the predelay for the TurboGrafx reset line issue (but the patched system card does), so it may erroneously fail on some TurboGrafx's - but not on a PCE or Duo.

[Localizations, Games, Apps, Docs / Re: CD Stupid Card 4.0]

Sorry if it was already mentioned, but I assume this card will not support arcade card pro games? I mean, physically impossible to support?

No worries.
But yeah, this card can't support the mapper used in the Arcade Card (Pro). You'd need a larger CPLD (especially in terms of pin count) in order to handle the paging scheme and extra features it has.

If I design another card maybe that will go in. I'd need to actually buy an Arcade Card and confirm it does what the publicly available documentation says first.

[Localizations, Games, Apps, Docs / Re: CD Stupid Card 4.0]

Hey everyone,

Sorry to bump this topic - but I've been getting PM requests to sell off the extra CD Stupid Cards I have. This is fine, but before I sell any of these I want to make sure everyone's purchased cards are still working fine (since these extras are effectively the "warranty replacements").

If anything has gone awry with your cards, get in touch with me within the next month.

[Localizations, Games, Apps, Docs / Re: CD adpcm and SOX]

/START RANT/
BTW ... how is it that I can drag a 20-year-old project out of retirement that was written for Visual Studio 6, and just load it up into a modern version of Visual Studio, and the thing just compiles and runs straight away ... but yet the "experts" at GNU keep on breaking their damned GCC source code so that newer versions of the toolchain won't compile older versions of the GCC compiler???
/END RANT/

Not that GCC is "bad," or anything - but Microsoft has put a huge amount of resources into source migration and compatibility specifically because there are companies which still use VS6 (and will only upgrade if it won't cost anything).

Of course, you can just keep using VS6 for new development if you don't care much about 64-Bit and keep in mind all the differences between Windows flavors (seriously though, VS6 even supports DLL Delay Loading, that is pretty modern as far as features go).

Constant rewriting is the GNU way, if a git repo stops moving it dies or something.

[Localizations, Games, Apps, Docs / Re: PC-FX homebrew development.]

If you know for sure that your code is running at 60Hz, you could always wait for raster count 261, and then wait again for "disp" to go to zero (which is probably the vertical-blank).

That's horrible, but it might work.

If it were me doing this, then I'd just figure out how to hook the vblank-interrupt with a small assembly-language function, and implement a counter.

I don't think we're going to find a PAL PC-FX in some NEC dumpster any time soon.

In the long run the hook is required if you start doing complex raster effects. May as well get it out of the way and then not think about it.

To be honest ... I personally believe that the V810 is the best designed and most-programmer-friendly of all the 5th-Generation CPUs (including the 3DO's ARM!).

You don't have to actually think about any of the "nasty" gotchas from those 1st-generation RISC architectures ... it has hardware-interlocks so that you can just code as you see fit (you just lose a few percentage-points of performance).

IMHO, the PlayStation's and N64's MIPS CPUs are ugly-but-bearable. The Saturn's SH-2 is an abomination, and just shows Sega's continued inability to design elegant hardware. The 3DO's ARM chip is really nice ... but a classic CISC architecture.

But the V810 is actually the first well-designed, programmer-friendly RISC chip that I've ever seen.

Which is such a shame, since the rest of the PC-FX doesn't really live up to the CPU.

MIPS is fantastic if you're a compiler.

I have to wonder if most of Sega's odd console hardware choices are from taking their arcade designs (which are very reasonable) and trying to rip features out until it reaches a consumer price point (which is never reasonable). The company as a whole is such a great case study.

I guess that we've all got our own comfort-zones.

This is definitely a factor.

The nice thing about console hardware (especially old hardware) is that every single platform has something "wrong" with it. We get to pick the "least bad" option.

[Localizations, Games, Apps, Docs / Re: Xanadu I and II - General Translation Project(s) Thread]

The only exception to that is going to be trying to implement a drop-shadow on the font in Xanadu 2 ... and that's because in-my-experience it is really important to have good contrast between the font and the background when displaying a single-pixel-width line on a CRT TV at 256-wide resolution.

At least the resolution is 256 pixels wide and not 320. Also the typeface isn't RED
NTSC artifacing is great until it isn't.

[Localizations, Games, Apps, Docs / Re: CC65 and the PCE]

Tailchao is probably doing his own engine so he has complete control over all variables that go into resource management of it, as well as any distinct features he wants to use.

Actually, the whole reason I wrote HuSound was to force myself to start writing (NULL == pValue) instead of (pValue == NULL) before starting a new job.

Although yes, it is partially a resource management thing. The driver and toolset are a complete overkill for what most games need. But I think it's easier to take extra features out later on rather than have to jam them in near ship time. The composer can do whatever they want and we put off optimization until later.

It's one of those fun projects for a programmer to do, with quick feedback (i.e. it makes noises), and it's also easy to convert a simple MIDI tune into something that you can experiment with.

Absolutely. It's also a great way to learn about music if you're not a composer. I usually just make the characters move.

[Localizations, Games, Apps, Docs / Re: HuSound]

You could always use blargg's sound engine (hes player) source code and interface it with some specific gui/code for your pce sound engine.

Huh, I didn't think of that approach. That could definitely work.
It's nice that so many tools are being made available 

Long term I definitely need a SASS graphical suite, since it's being used on more targets than just the PCE. Being able to just draw notes on a staff is great.

Do you buffer your reg changes, so that they all happen near the same time? So pairing channels for phase effects, the channels get updated near synchronously?

Yeah, that's actually one of the reasons the memory consumption is a little high. My Lynx driver doesn't do this since the resources are so constrained, but it definitely helps with the macro setup.

So for HuSound updates you do two calls : one right at the beginning of your VBL IRQ (HuSound_WriteBack) which dumps all of the register updates calculated on the last frame, then one at the end of the IRQ (HuSound_Main) which calculates the next register update set and is interruptable.

[Localizations, Games, Apps, Docs / Re: HuSound]

Heh - I thought some of my engines were too mechanical in nature (I always worried that other people would be put off by the complexity). I can visualize that, though, having created music engines and fussing over ticks and divisors/counters.

Yeah, it's difficult to get a good balance for a scripting language. I'm still not completely happy with some the choices I made in SASS (especially with how 16.8 or 16.16 values are entered). Graphical editors will knock down most of the learning curve, especially for creating instruments.

One nice thing about SASS is that once your very complex macro is written, all of that functionality is reduced to one "using" statement in your music script :

Code Select Expand

using CasioTrumpet
...
c.4 14
rest 1
c.4 14
rest 1
e.4 24
rest 5
b.4 25
rest 5
...
You can also use abbreviated commands, i.e. "f" for "frequency" or "l" for "loop" when you get more comfortable with the language.

In any case, all of this is still easier than creating patches for very ancient analog synths 
But I would like to write a proper graphical editor at some point.

[Localizations, Games, Apps, Docs / Re: HuSound]

I was reading the manual.. how do you do volume and vibrato envelopes?

All control over an instrument's envelope is done through its macro script. If you look at ./HuListen/SASS/Instruments.txt in the library download or ./Instruments.txt in the Secret SASS download you can see the basic instrument set I've used for most of the test songs and covers.

The big learning curve is that everything in SASS is a script, there are no predefined envelopes. So you're free to do ADSRAR or whatever you want instead of just ADSR.

The first instrument is actually a good example of a volume envelope among other things.
Let's walk through it :

Code Select Expand

CasioTrumpet
; Approximation of Earthbound / Mother's Trumpets.
; Uses the same waveform as the CasioTone instrument, but has
; a much slower attack phase giving it a brass / wind quality.
;-----------------------
{
wave 0,4,12,24,28,29,28,24,12,8,4,3,2,2,1,1 0,2,6,12,14,15,14,12,6,4,2,2,1,1,0,0
frequency 6 -1
volume 20 2
tuning 16.0
{
rest 4
volume 30 -1
rest 2
frequency 0
volume 28 -2
rest 2
volume 22 0.113
loop -1
wait 9
volume 26 -0.113
wait 9
volume 22 0.113
endloop
noteoff
volume 24 -1
wait 18
end
}
}
The parameters inside the first set of curlybraces right after the instrument name are the initial settings. I set the waveform and initial envelope operations here. We're interested in the latter, which are :

Code Select Expand

frequency 6 -1
volume 20 2
...The first line (frequency 6 -1) sets the instrument's frequency offset, and how that will change over time. When an instrument is played, its final frequency is the sum of its current note, any active pitch bends, and this offset value. We're setting this to 6, which increases the divider value and gives us a lower frequency. The second parameter of -1 indicates how the frequency offset will change over time. In this case it decreases by 1 per tick. So the pitch of the instrument is increasing.
The next line (volume 20 2) does the same, except for amplitude. We set an initial volume of 20 (out of 31), and will add 2 to it each driver tick. So we're getting louder.

That's our attack phase.

Continuing onward :

Code Select Expand

{
rest 4
volume 30 -1
...We've hit a rest command, whose argument indicates we're not going to advance our script for 4 frames. Note that rest and wait are interchangeable in instrument scripts, but have different meaning in music scripts. I use both here.
Meanwhile, the frequency and volume envelopes are still calculating in the background. So by the time four frames expires :

Volume = 20 + (2 * (4 + 1)) = 30
Frequency / Divider Offset = 6 + (-1 * (4 + 1)) = 1
Some drivers I wrote pre-add these values on any change, so you need to bias the frame count by one. I think HuSound is one of these. Yay, standards.

Anyway, our next command is volume 30 -1. The volume is getting quieter, and we're starting our decay phase.

Let's skip ahead, since you've likely picked up what's going on by now. A little further down is our first loop :

Code Select Expand

...
volume 22 0.113
loop -1
wait 9
volume 26 -0.113
wait 9
volume 22 0.113
endloop
...We set the volume to increase and then enter the loop body with a loop count of -1. This is an infinite loop, and it will continue until either the song hits a note off command, is manually stopped, or the channel is taken over by a sound effect.
Looking at the body of the loop, I'm just delaying for a bit, then reversing the direction of the volume envelope, effectively doing this : /\/\/\/\/ ... during the instrument's sustain period.
Replacing this with a frequency command will effectively give you vibrato. You can make the differentials very large and the delays very small to get arpeggios.


Now about note off commands -
We're effective looping in the sustain period above, and will stay there until we hit a rest / note off command in the music script. Once we hit one of those, the instrument script will JMP to the tagged note off area of its script (if the instrument still has control of the channel).

If we look right below the loop body, you'll see :

Code Select Expand

...
endloop
noteoff
volume 24 -1
wait 18
end
}
The noteoff tag is where the instrument will jump. If you look right after it, I'm setting the volume to decrease and then telling the instrument to terminate.


Hopefully all this is clear! SASS can be a little difficult.