Author Topic: PC-FX homebrew development.  (Read 17547 times)

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: PC-FX homebrew development.
« Reply #165 on: March 17, 2016, 12:39:28 PM »
OK so what I have done then is created two functions... one pauses the program until the raster line is below 1, and another that pauses the program until the raster line is above 0. Is there enough time in between these two points to do drawing and such, or am I better off just checking for 0 and skipping the second one?

Well ... I'd read the docs, which Google Translate butchers as ...

b. RASTER COUNT (bit5 ~ 13)
I shows the raster number currently being displayed on the CRT. Display period is up to 22-261.
It should be noted, does not match the scanning line number that is defined in the NTSC signal.
During external synchronization, I will be 1FFH if the external sync signal is disturbed.

Note) of raster number value, you need to be sure you read more than once since become undefined by the timing to be read is constantly updated.


So you've got a range of values for the 239 lines of the actual display, with no extra values during the vblank period.

It depends upon what you're trying to do.

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.

nodtveidt

  • Guest
Re: PC-FX homebrew development.
« Reply #166 on: March 17, 2016, 12:51:06 PM »
I hate counters, hooking interrupts, and RISC assembly. :lol:

I did a test where I measured the high and low with eris_tetsu_get_raster()... the range was 0 to 261 (makes sense, since I'm telling tetsu to use 262 lines). Also, I tested getting rid of the second pause, and things worked the same as using it, so it looks like there's no point in using that second pause.

...and yeah... that's some severely butchered language there... :lol:

Mednafen

  • Full Member
  • ***
  • Posts: 140
Re: PC-FX homebrew development.
« Reply #167 on: March 17, 2016, 02:53:58 PM »
eris_tetsu_get_raster() may occasionally return a garbage value on real hardware as it doesn't appear to follow the hardware programming manual's advice.  You can call the function multiple times to work around it, but that's not as efficient as having the workaround for the hardware bug in the function itself...

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: PC-FX homebrew development.
« Reply #168 on: March 17, 2016, 04:16:27 PM »
I hate counters, hooking interrupts, and RISC assembly. :lol:

Well, I guess that's pretty-much-why I'm spending my time banging my head against the brick-wall of GCC!  ](*,)

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.

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


eris_tetsu_get_raster() may occasionally return a garbage value on real hardware as it doesn't appear to follow the hardware programming manual's advice.  You can call the function multiple times to work around it, but that's not as efficient as having the workaround for the hardware bug in the function itself...

Thanks! I wasn't sure if that was a "real" warning in the docs, or just a bad artefact of Google Translate.

I'll fix the liberis function to actually read the value a couple of times and make sure that it's stable.

I just "fixed" Alex's startup code to do a faster job of clearing "C"'s BSS segments on startup ... partially for the performance improvement, but mostly to avoid having to dig much deeper into whatever-it-is that I broke in GCC's stack code (I think that I know, I'm just not enjoying the thought of fixing it).

While you're "on-the-line" ... can I ask if you've seen anything in the PC-FX BIOS or libraries that uses the R2 and R5 registers?

AFAIK, they're not used except temporarily-during-startup, and I'd like to use them for the Frame Pointer and the Thread Local variables pointer.

SamIAm

  • Hero Member
  • *****
  • Posts: 1835
Re: PC-FX homebrew development.
« Reply #169 on: March 17, 2016, 05:42:38 PM »
Quote
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.


Interesting. It makes me wish I understood more about processors and programming.

When it comes to Sega, in addition to whatever poor choices the engineers were making, it seems to me that the executive side may have been steering them into bad ideas as well. Sega had a relationship with Hitachi - I think they were manufacturing the 68000s and other components in the Mega Drive, and there are even rumors that Hitachi execs and Sega execs were golfing buddies. Not to mention, I wouldn't be surprised if there was also a reluctance to use non-Japanese parts.

Don't let me derail the thread, though.  :wink:

EDIT: Here's a Japanese article I just found that tells at least some of the story of how Sega chose the SH-2, from the perspective of a Hitachi engineer, published in an industry magazine in September 1997.

http://japan.renesas.com/products/mpumcu/superh/related_sh/theme/story/06.jsp

Some interesting points:
- The SH-1 was completed by 1992, but nobody was buying it.

- Hitachi approached Sega about using it in summer 1992. Interestingly, their first meeting wound up taking place in the Sega cafeteria.

- Sega rejected the SH-1 as it was. They told them to come back with 1) improved multiplier performance, 2) synchronous DRAM interface circuits installed, 3) the ability to meet certain game-oriented benchmarks.

- Hitachi started mass producing the SH-1 before they had any buyers for it. The lead engineer was frustrated with this and with the general work environment, and was about to take a job at another company. He submitted his intention to resign and everything.

- The vice president of the Hitachi's semiconductor subsidiary called him, buttered him up, and asked him to stick around a while longer.

- Rather suddenly, Sega accepted the SH chip for its next game system in autumn 1992. Hitachi started working an an improved SH-2 soon after.

- In summer 1993, Sega complained to Hitachi that the SH-2 wasn't powerful enough. In September, there was a big meeting of top people from both companies, and Hitachi apparently revealed a "secret strategy" - put two of them together.

- By March 1997, Hitachi had sold 15 million SH-2s through Sega. However, the profits weren't good because Sega was so desperate to keep costs down.
« Last Edit: March 18, 2016, 02:47:17 AM by SamIAm »

TailChao

  • Full Member
  • ***
  • Posts: 156
Re: PC-FX homebrew development.
« Reply #170 on: March 18, 2016, 04:07:34 AM »
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.

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: PC-FX homebrew development.
« Reply #171 on: March 18, 2016, 04:59:44 AM »
Don't let me derail the thread, though.  :wink:

Hahaha ... I like tangents!  :wink:


Quote
EDIT: Here's a Japanese article I just found that tells at least some of the story of how Sega chose the SH-2, from the perspective of a Hitachi engineer, published in an industry magazine in September 1997.

Thanks, that's very interesting.  :-k

Here's a Hitachi marketing-brief about the SH-2 from back around that time-period ...

http://www.hotchips.org/wp-content/uploads/hc_archives/hc06/2_Mon/HC6.S4/HC6.4.2.pdf


Quote
When it comes to Sega, in addition to whatever poor choices the engineers were making, it seems to me that the executive side may have been steering them into bad ideas as well. Sega had a relationship with Hitachi - I think they were manufacturing the 68000s and other components in the Mega Drive, and there are even rumors that Hitachi execs and Sega execs were golfing buddies. Not to mention, I wouldn't be surprised if there was also a reluctance to use non-Japanese parts.

That sounds like your typical "business" scenario.

Hitachi's early CPU successes were in being a licensed second-source for American CPUs, and often improving them ... such as their HD64180 (improved Zilog Z80) and their HD6309 (improved Motorola 6809). Hitachi's relationship with Motorola gave them first the 6809, and then the 68000 (which they sold to Sega for the MegaDrive, and then also the Saturn).

AFAIK, the SuperH series (SH1, SH2, SH3) was one of their first home-grown designs ... and they made a bit of a mess of it.

It's still the only CPU that I know of that has 2 different instructions, with different names, and different binary codes, that do exactly the same thing.

It also misses out a bunch of useful things, which means that you end up needing to use multiple instructions to accomplish what other RISC architectures can do with a single instruction.

Their "secret strategy" of throwing 2 SH-2 CPUs together in the Saturn and the 32X was an absolute joke, and just a marketing gimmick to claim double the processing power. In reality, the each CPU could pretty-much completely use the entire memory bandwidth by itself, and so pairing the 2 of them on a single bus just lead to massive bus-contention and starvation for each processor.

They tried to mitigate this by re-purposing the 4KB of write-through-cache into internal memory in order to reduce the bus-contention, but that was a joke because the 5th-generation machines were all supposed to be programmed in "C", and neither the language, nor any of Sega's libraries could actually take advantage of that little 4KB of uncontested memory.

Which is why nearly-all early Saturn games just disabled the 2nd CPU and ran entirely on the 1st CPU ... throwing away 50% of Sega's marketing-hype performance.


The PC-FX's V810 (and the PlayStation's MIPS R3000) don't have the raw fake-benchmark performance numbers of the SH-2, but they easily make up for it in practice by providing "usable" performance.

IMHO, the PlayStation is the 5th-generation equivalent of the PC Engine. It's an elegantly-designed machine that does exactly what it's designed to do, and does it very, very well. But since it's basically a super-Amiga, with a fast blitter for 2D games, and good-for-its-time-but-poor-in-hindsight 3D performance, it's just a little bit "boring" to program.

The PC-FX is like a C-programmable SuperGrafx, with some extra SNES-like background layers and video too. It's just a more-interesting 2D machine, especially if you contemplate using the HuC6273 chip that's on the PC-FXGA to give you Saturn-like 3D capabilities (or just lots of sprites).

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: PC-FX homebrew development.
« Reply #172 on: March 18, 2016, 05:48:59 AM »
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.

I agree ... but as-for-myself, I'm too busy at the moment working on other things (like the Xanadus and trying to get GCC "fixed").

Well ... that and pontificating in interesting threads! :roll:


Quote
MIPS is fantastic if you're a compiler.

Which is OK in 2016 ... but the quality of the compilers back in 1995 was pretty bad. You pretty-much-had-to drop down into assembly for any speed-critical routines.

But "yeah", MIPS's delay-slots aren't that nasty to program-around. IIRC, my distaste at the time was more to do with my lack of a decent assembler.

By the time that the N64 came around, that had been fixed by the guys at Cross-Products and PsyQ ... but the N64 had it's own "mysteries" with the RSP.


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

The choice to ship with 2 PCE VDP chips is definitely bizarre.

The choice to ship with the PCE sound-chip is a bit regretable, but just follows-on from NEC's years of promoting CD-audio and premixed-ADPCM in games.

The PC-FX's own custom chips, the HuC6271 for video, the HuC6272 for backgrounds and SCSI, and the HuC6273 for "3D" sprites, seem to be pretty-nice, and very much remind my of a Saturn-done-right-but-a-bit-less-powerful-and-a-lot-more-usable.


Quote
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.

There's definitely a huge difference in practical design-philosophy between the throw-everything-at-it-and-damn-the-cost arcade boards where you're charging thousands of dollars each to a select-few customers in order for them do suck the quarters out of people's pockets, and the let's-sell-millions-cheaply console market.

Sony's PlayStation is a perfect example of that. It's a very "minimal" hardware design, with the costly chips put exactly where they're needed.

The Saturn, OTOH, is an absolute joke of a design, with expensive bits-and-bobs thrown everywhere and lots of stuff just sitting there idle because it's got nothing to do most-of-the-time.


Quote
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.

Hahaha ... "yep"!  :wink:

Mednafen

  • Full Member
  • ***
  • Posts: 140
Re: PC-FX homebrew development.
« Reply #173 on: March 18, 2016, 07:31:12 AM »
While you're "on-the-line" ... can I ask if you've seen anything in the PC-FX BIOS or libraries that uses the R2 and R5 registers?

AFAIK, they're not used except temporarily-during-startup, and I'd like to use them for the Frame Pointer and the Thread Local variables pointer.

No, but I haven't really dug into the BIOS and official dev libraries that much.

nodtveidt

  • Guest
Re: PC-FX homebrew development.
« Reply #174 on: March 18, 2016, 11:08:16 AM »
OK so on another subject... I am now starting to delve into the tools we have at our disposal, now that AGE is translated. I took a 32x32 BMP image and converted it to a 6270 sprite. AGE expanded it to 128x128. Dafuq?

ccovell

  • Hero Member
  • *****
  • Posts: 2245
Re: PC-FX homebrew development.
« Reply #175 on: March 19, 2016, 02:40:14 AM »
It's still the only CPU that I know of that has 2 different instructions, with different names, and different binary codes, that do exactly the same thing.

CLA when you have LDA #0  when you also have XOR A,A
SHL A when you have ADD A,A...

(Well, I guess with completely orthogonal instruction sets, such things are inevitable.)

The Saturn, OTOH, is an absolute joke of a design, with expensive bits-and-bobs thrown everywhere and lots of stuff just sitting there idle because it's got nothing to do most-of-the-time.

Your description there completely reminded me of how local municipalities (and their workers) operate over here in Japan...  :-|

nodtveidt

  • Guest
Re: PC-FX homebrew development.
« Reply #176 on: March 19, 2016, 05:42:40 AM »
I modified trap15's sprite example to fill VRAM with an array rather than noise.



But this is as far as I got. If I try changing the size of the sprite (using either eris_sup_spr_create or eris_sup_spr_ctrl), it vanishes. There is also no update code in the example program so it makes me wonder how the sprite's position is ever updated at all... unless liberis is automatically updating the SATB any time a change is made...

EDIT: Wait a minute... am I right in reading that the FX's 6270s can only make 16x16 sprites, completely f*cking over one of the best features of the same chip on the PCE?
« Last Edit: March 19, 2016, 05:50:58 AM by The Old Rover »

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: PC-FX homebrew development.
« Reply #177 on: March 19, 2016, 05:55:42 AM »
CLA when you have LDA #0  when you also have XOR A,A

Ooooh ... I'm definitely curious which CPU has both "CLA" and "XOR A,A". I wouldn't count "LDA #0" because that would probably have an extra byte in the encoding, or an extra cycle in execution, and possible even different flag settings.

Quote
SHL A when you have ADD A,A...

(Well, I guess with completely orthogonal instruction sets, such things are inevitable.)

Yep, with those instructions it would depend upon the allowed addressing modes for each instruction.

*************

But the SH-2 has ...

Format:      SHAL Rn
Abstract:    T ← Rn ← 0
OpCode:      0100nnnn00100000
Description:
Arithmetically shifts the contents of general register Rn to the left by one bit, and
stores the result in Rn. The bit that is shifted out of the operand is transferred to the T bit.

Format:      SHLL Rn
Abstract:    T ← Rn ← 0
OpCode:      0100nnnn00000000
Description:
Logically shifts the contents of general register Rn to the left by one bit, and stores
the result in Rn. The bit that is shifted out of the operand is transferred to the T bit.

2 instructions that do exactly the same thing.


They're complemented by ...

Format:      SHLL2  Rn
Abstract:    Rn << 2 → Rn
Format:      SHLL8  Rn
Abstract:    Rn << 8 → Rn
Format:      SHLL16 Rn
Abstract:    Rn << 16 → Rn

Format:      SHAR Rn
Abstract:    MSB → Rn → T
Format:      SHLR Rn
Abstract:    0 → Rn → T

Format:      SHLR2 Rn
Abstract:    Rn >> 2 → Rn
Format:      SHLR8 Rn
Abstract:    Rn >> 8 → Rn
Format:      SHLR16  Rn
Abstract:    Rn >> 16 → Rn


Errrmmmm ... WTF happened to "SHAR2", "SHAR8" and "SHAR16"??? They'd actually be useful, but they're nowhere to be found.

Definitely a CPU designed by a hardware engineer that never had to actually program a line of code in his life.

Of course, any self-respecting CPU designer from the time would just have put in a barrel-shifter, and provided "SHLL/SHLR/SHAR Rn,Rn" instead of that rat's-nest of stupid instructions.


Quote
Your description there completely reminded me of how local municipalities (and their workers) operate over here in Japan...  :-|

Hahaha, so true everywhere!  :wink:

nodtveidt

  • Guest
Re: PC-FX homebrew development.
« Reply #178 on: March 19, 2016, 06:18:58 AM »

Getting somewhere... but this is rather convoluted and quite different than working with the same chip on the PCE.

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: PC-FX homebrew development.
« Reply #179 on: March 19, 2016, 06:37:50 AM »
Wait a minute... am I right in reading that the FX's 6270s can only make 16x16 sprites, completely f*cking over one of the best features of the same chip on the PCE?

Nope, you're missing something in the docs, or Google Translate is messing things up for you.

It's exactly-the-same VDC chip that's in the PCE, and it has the same 32x64 maximum sprites with the size-bits in the same place.

I think that you may be expecting a little-too-much from the current-state of liberis.

Alex has provided all the critical background stuff in there ... but the higher-level "engine" stuff (like SATB updates) is completely-missing AFAIK.

That's where you get to read the SDK docs, and perhaps get-your-feet-wet with some V810 assembly language ... or not.


Getting somewhere... but this is rather convoluted and quite different than working with the same chip on the PCE.

I'm glad that you're making progress!

It's exactly-the-same chip, with exactly-the-same data formats, how is it different to work with?