There is a Saturn emulator on Dreamcast!

[tr0ll]

It is a thought but we would need a skilled SH4 ASM programer . And not use kos or a dev kit.

Emphasis on the latter half of that placed by me. It's just not true. What do you think any set of compilers and libraries is? That's right, a "dev kit." There's nothing about KOS that makes it inherently unsuitable for writing an app such as this with. Thanks to these things called ABI and calling conventions, you can write your entire emulator in assembly and still call all the functions already provided for you, like input handling, or video/3D rendering, keeping you from having to rewrite years worth of well-debugged and decently performing code. There's far more critical parts of the application that would need to be sped up, and that's where the assembly language would come in handy (in most cases just to increase the spatial locality (and density/brevity) of the important parts of the code, like CPU cores or video code).

[Ian Micheal]

Bleemcast did not use any dev kit the speed was a lot better . Because it was hand tuned SH4 Asm . I asked how it was made it used no dev kit at all Pm rand find out. Kos does add a layer any layer reduces speed. Bleemcast talked directly to the hardware and had no layer to go throu. It could not of been made so well using kos and GCC which is not any good for the dreamcast and was never made for it. We all know that any way any SH4 ASM using GCC and kos breaks as soon as you use a flag above -02 that is hardly going to do the job with the tools we have. You would have to write the custom linkers and write SH4 asm to talk directly to the hardware.

[Hobbes T Tiger]

All this talk of Dev kits and direct hardware control is meaningless.

Everyone knows that each Saturn had a specially bred Sega employee inside who worked a switchboard connecting the processors.

And he span the CD Drive. That's why it was so slow. He was very small and not very strong.

And why Saturn is so darn heavy.




Sorry...

[Ian Micheal]

All this talk of Dev kits and direct hardware control is meaningless.

Everyone knows that each Saturn had a specially bred Sega employee inside who worked a switchboard connecting the processors.

And he span the CD Drive. That's why it was so slow. He was very small and not very strong.

And why Saturn is so darn heavy.




Sorry...

Hahah ! Thats funny dude loFL!

[Alexvrb]

Just to clarify masks post, the DC has the following:

2x Hitachi SH-2 32-bit 28.6 MHz
1x Hitachi SH-1 32-bit 20 MHz
1 x VDP1 sprite and geometry processor
1 x VDP2 background processor
1 x Motorola 68EC000 11.3 MHz
1 x Yamaha FH1 DSP

All that on a lightly toasted seseme seed bun

I think you mean the Saturn

And you missed a DSP. There's another one that's there specifically to help out with matrix calculations (for the conversion of the vertices from 3D to 2D so they can be rendered). Just about every specs page on the Saturn ignores this (probably because most games didn't use it).

Which chip is this? Is that what the Saturn Control Unit does, because I mentioned it. I just don't know much about its functionality.

[Mask of Destiny]

I thought it's part of the SCU, but I'm not 100% certain. I'd have to look in the docs again. I just remember the description of it's purpose.

[tr0ll]

God reaper. You just don't get it. He ended up writing libraries of his own, that are functionally equivalent if not (how much?) better in performance than the ones featured in KOS. But guess what, when he was done, do you know what he had? Yeah, that's right, a "dev kit." And it didn't add any more of a 'layer' than KOS would. You can also tune KOS as much as you want if you feel it necessary, to get the most performance. The big thing against the Saturn is simply the massive complexity of the hardware. I wrote demos for the N64 and Saturn back in the day, and know first hand that the difference between their complexity, despite the N64 being more 'powerful', is absolutely amazing (enough so that I'd say limited but correct N64 emulation on the DC would be possible whereas any Saturn emulation would be nigh on impossible to get right). The Saturn is like the PS2 in design, powerful but a fcking nightmare in design and to program to get your code running *well*.

Also good to note, GAS does NOT break your assembly. If you hand-code assembly and run it through the assembler (note, NOT the compiler) it produces a direct machine-code translation of your finely-crafted code in an object code file ready to link. And this can still link to any other code that you compiled with GCC separately (in that case it would be up to you to use proper compiler settings. Just because you set -O9, doesn't mean the code that comes out of the back-end of the compiler is going to be any good. Most of the time -O3 hurts more than it helps compared to -O2 anyway). You wouldn't need a custom linker. Writing SH4 assembly 'to the hardware' isn't as big a deal as you make it out to be either. The parts that need the most speed first and foremost would be the CPU emulation. That relies very little on hardware besides the CPU itself. The assembly is processor specific but certainly not all that hardware specific (it's not going to need to directly interface with the PVR!). Trust me when I say I know more about this then you do. Hell, I've written and hand-assembled my own IP.bin bootloader... write me back when you get that far...

[Ex-Cyber]

God reaper. You just don't get it. He ended up writing libraries of his own, that are functionally equivalent if not (how much?) better in performance than the ones featured in KOS. But guess what, when he was done, do you know what he had? Yeah, that's right, a "dev kit."

The phrase "dev kit" typically refers to a set of libraries and tools to facilitate general-purpose development on some platform, not an arbitrary collection of routines optimized for a particular program.

edit: I hasten to add that if you know something in particular about Bleemcast that Reaper and I don't, that's another issue. I'm just trying to draw the distinction Reaper is talking about a bit more clearly.

You can also tune KOS as much as you want if you feel it necessary, to get the most performance.

Depending on the application, you may end up reimplementing KOS from the ground up, defeating the purpose of using a dev kit.

I'd agree with pretty much everything else though.

And for those who were wondering, yes, the "other" DSP is housed in the SCU. Simply rolling it in with everything else as "the SCU" is kind of misleading though, as it's really its own functional unit that just happens to be easier to connect to everything by being inside the SCU. The SCU has other vitally important functions like interrupt control, implementing the A-bus and B-bus, and performing cross-bus DMA, that are mostly unrelated to the DSP.

edit: BTW, the SH-1 was not exposed to Saturn programs, it runs the (quite powerful) CD interface behind the scenes; the emulator just needs to implement the CD interface. People usually list it in the Saturn's processors, but from a practical standpoint it's just glue unless you can dump the internal ROM.

[Mask of Destiny]

I have no idea how Rand went about writing Bleemcast, but there's nothing that requires him to have written a proper dev-kit in the process. If your only code that interfaces with the hardware just translates writes to the emulated video processor to the appropriate PVR ones, it would have no use beyond the emulator. It's debatable to whether you'd get any appreciable speed gain going this route though theoretically you would shave off some overhead.

I've written and hand-assembled my own IP.bin bootloader

Do you mean, wrote the assembler by hand or translated the assembler into binary opcodes by hand? If it's the latter that must have been rather painful. I did a little bit of hand-assembly on the Z80 and that was tedious enough with just 8-bit opcodes. I can't imagine how much "fun" it would be to do the same on the SH-4

[Ex-Cyber]

I did a little bit of hand-assembly on the Z80 and that was tedious enough with just 8-bit opcodes. I can't imagine how much "fun" it would be to do the same on the SH-4

Well, Z80's opcode assignment may as well have been random in lots of places, being that it was essentially an expanded 8080. And with something like SuperH, in a lot of cases half the instruction word is specifying source and destination registers anyway; it's not like there are actually thousands of different opcodes to memorize - not to mention that most older processors have 5 or 6 different opcodes doing the same thing in different addressing modes where e.g. SuperH or MIPS would just put the address mode differences into the move instruction and have everything operate on registers. So really it's not as bad as you might think, but still tedious of course.

[tr0ll]

Mask: it was the latter, and it was painful, but I was too lazy to do anything more. It didn't really bother me anyway, because back in those days I had nothing better to do. The big problem just comes from reencoding addresses when you add more code. Otherwise, it's pretty fun .

[antidot]

That would be an amazing feat. I could see it possible for all that is said above, but the sheer time it would take the programmer, we could work a few days and buy a Saturn.

[Alexvrb]

Are you saying fullspeed, antidot? I'd say not a chance, especially with sound.

[Ian Micheal]

God reaper. You just don't get it. He ended up writing libraries of his own, that are functionally equivalent if not (how much?) better in performance than the ones featured in KOS. But guess what, when he was done, do you know what he had? Yeah, that's right, a "dev kit." And it didn't add any more of a 'layer' than KOS would. You can also tune KOS as much as you want if you feel it necessary, to get the most performance. The big thing against the Saturn is simply the massive complexity of the hardware. I wrote demos for the N64 and Saturn back in the day, and know first hand that the difference between their complexity, despite the N64 being more 'powerful', is absolutely amazing (enough so that I'd say limited but correct N64 emulation on the DC would be possible whereas any Saturn emulation would be nigh on impossible to get right). The Saturn is like the PS2 in design, powerful but a fcking nightmare in design and to program to get your code running *well*.

Also good to note, GAS does NOT break your assembly. If you hand-code assembly and run it through the assembler (note, NOT the compiler) it produces a direct machine-code translation of your finely-crafted code in an object code file ready to link. And this can still link to any other code that you compiled with GCC separately (in that case it would be up to you to use proper compiler settings. Just because you set -O9, doesn't mean the code that comes out of the back-end of the compiler is going to be any good. Most of the time -O3 hurts more than it helps compared to -O2 anyway). You wouldn't need a custom linker. Writing SH4 assembly 'to the hardware' isn't as big a deal as you make it out to be either. The parts that need the most speed first and foremost would be the CPU emulation. That relies very little on hardware besides the CPU itself. The assembly is processor specific but certainly not all that hardware specific (it's not going to need to directly interface with the PVR!). Trust me when I say I know more about this then you do. Hell, I've written and hand-assembled my own IP.bin bootloader... write me back when you get that far...

Well heres a quote off my forum we talked about bleem cast in detail and what it used why do you think i said it used no dev kit. I thought the same as you at first. but sorry to say your wrong.

They did not use a development kit of any kind - they programmed the hardware directly.

They did not use a compiler - they coded the entire thing in SH-4 assembly. That means no C code whatsoever. They used an assembler, and possibly a linker, nothing more.

So there is no devkit, there is no library, and there is no compiler. The emulator runs directly on the hardware, and manipulates everything itself.

Does that anwser you Troll next time check your facts. NO dev KIT was used GET it


Why dont you help us all out with some SH4 tuts for dreamcast and show us the ip.bin you coded maybe it can be a legal replacement .

[tr0ll]

You can never have a fully legal ip.bin because theres a part of the code you can't change, or the DC won't boot it.

I was applying the phrase "dev kit" in a more liberal fashion to get you off of your whole one-track "only asm is the way to go" thing. I know how BleemCast works, hell I used to talk to Rand in PMs back in the #dcemu chat all the time. We had some great discussions, he gave me some hints for my SH4 assembly MIPS code, and we had some other interesting technical disccusions including about how the Doom SNES renderer worked, in extremely low-level terms. Suffice it to say, I think I have a better idea of what's going on and about what I'm posting than you do.

As far as SH4 assembly tutorials, I could pick out some choice snippets of code that help you do the basic things like walk through arrays, or load stuff from memory into registers, and the simple operations that you'd do on them, if it was really something a lot of people wanted to see. Writing assembly isn't hard, writing assembly well is.

[Mask of Destiny]

You can never have a fully legal ip.bin because theres a part of the code you can't change, or the DC won't boot it.

One could argue that this would still be perfectly legal by the precedent set in Sega vs. Accolade. Granted that was primarily trademark and this is copyright, but they're both under IP law and the principle is the same.

Writing assembly isn't hard, writing assembly well is.

Especially on modern processors. Hand optimizing code is a lot more complicated in a world of piplines, caches and superscalar CPUs.