4 ms·

I do Dreamcast homebrew (https://www.youtube.com/watch?v=2uZP9iOQc6E https://www.youtube.com/watch?v=2uZP9iOQc6E) (https://www.youtube.com/watch?v=MlFu-y1LDbs h

by TapamN 8y ago

I do Dreamcast homebrew (https://www.youtube.com/watch?v=2uZP9iOQc6E https://www.youtube.com/watch?v=2uZP9iOQc6E) (https://www.youtube.com/watch?v=MlFu-y1LDbs https://www.youtube.com/watch?v=MlFu-y1LDbs) and I've thought about trying Saturn homebrew, but getting code to run on a Saturn has been more difficult than running it on a Dreamcast. With a DC, I just connect it to a computer through serial or ethernet, pop in a CD-R with a loader program, and I can easily upload and run code on it. On the Saturn, getting a loader to run it much more difficult since it requires some kind of console modification (like disabling the disc-door state detection in order to allow disc swapping, or getting hold of a sold-out disc drive replacement) or an ISA-only PC Comms Link card and a Pro Action Replay. (I do happen to own a PAR, but not a Comms Link card and would rather avoid setting up ISA compatible hardware just for one purpose.) Testing on an emulator is a terrible idea, because you have no idea if it will work on real hardware, and I like trying to come up with ways to break emulators anyways, so that option's no good. And... I was going to ask if you had any ideas for how to upload code in my situation, but I decided to search for "pc comms link saturn" while typing this and found a Bluetooth adapter for the PAR's comms port, so... I guess I just ordered one. Actually, I've been working on an SH-2/3 assembly blitting library to run on the HP Jornada 690, a palmtop computer which has a 133 MHz SH3-DSP as the CPU. One of my goals for the library is for it to run on a 32X (which I actually don't own), and a Saturn is much closer to a 32X than the Jornada, so I'll be able to get a better idea of it's actual 32X performance this way. And the Jornada really does use the DSP variant of the SH-3. I was disassembling the hardware initialization code of the boot ROM to figure out what it's memory timings were (to compare them to the 32X) and found it executing DSP instructions. I wrote a test program to double check, and it passed. The Jornada has a software modem, so the DSP capabilities are probably used for that.

lostgame 8y ago
Oh, for me, I absolutely use emulation, for obvious reasons, debugging and RAM/VRAM viewing/mapping being the obvious ones - I then use a tool provided by jo-engine that does all the tough work of creating an ISO file that I simply burn to my drive-door modified Model 1 NTSC Saturn when I want. It's not ideal. Nor, however, for me, is the Dreamcast's need for either an outdated serial port, or an expensive and rare broadband adapter. Furthermore, the Dreamcast just seems like one of the first systems that seemed extremely close to a PC. I love that I can still fiddle with assembly in very logical ways with the Saturn. I'm not sure if that's the case with the Dreamcast. (The DC, is, incidentally, one of my favourite consoles ever in terms of software!) For the Saturn, there is a new piece of software that can be uploaded to certain times of common/inexpensive Action Replay/Backup RAM carts that allows you to run standard burned CD's. I've meant to buy one for a while now, but sadly I haven't had the time I've wanted to prioritize Saturn dev in the last while due to adulting. :3
- TapamN 8y ago
  Well, not many DC emulators will run my code anymore, and eventually none will. :P On the DC, I used to use serial port with a USB adapter that manages 384k baud, but upgraded to a BBA several years ago. I really, really, don't like the idea of doing a bunch of development on an emulator, then finding out it doesn't work right on real hardware (either not at all or with unexpectedly terrible performance) and having to figure out what all is going wrong. Doing it all on a real console means you find out immediately where any problems arise. The Dreamcast tries to pretend to be like a PC, but treating it like one will seriously limit performance. The SH-4's terrible cache needs to be babied to get the most out of it, and there's a lot of unusual things you can do with the 3D hardware since it works very differently than other GPUs. You can definitely do assembly on the DC, and it's really important for performance critical code. GCC can't use the SH-4's SIMD instructions effectively, so you have to use at least inline asm or true assembly. I'm not totally sure what you mean by "in very logical ways". I guess optimal SH-4 code doesn't look logical! Rendering-type code is harder on the SH-4 than the SH-2/3 because it's superscalar and FPU instructions have longer latency than ALU instructions. You have to spend more time figuring out how to hide latencies, and software pipelining becomes more important for performance. Optimal SH-4 assembler code ends up much messer looking than optimal SH-2/3 code. For example, normalizing an array of 3D vectors in C, using inline assembly to use the inner product (FIPR) and square root reciprocal (FSRRA) instructions, you'd be lucky to get around 24-28 cycles per vector (it'd be even worse if you used pure vanilla C). But with software pipelined assembly, I can manage 8 cycles per vector. But it's much more complex, not just because it's in assembler. The optimized main loop juggles normalizing 4 vectors at the same time (The loop is 32 cycles, with 4 vectors it averages 8 cycles per vector), and there's code to prepare the loop and exit the loop, and special case code for if there are fewer than 4 vectors to transform. The resulting machine code for the entire asm version is probably around 10 times the simple version. Another example would be transforming a bunch of 4D vectors by a 4x4 matrix. C with inline asm will take about 16 cycles per vector, but optimized pure asm can do 4 cycles. A 3D rendering engine I'm working on for the DC does software vertex shaders by basically copy & pasting optimized assembly loops into a single function and adding a bit of glue code between them.
  - 8y ago

by TapamN 8y ago

lostgame 8y ago

Oh, for me, I absolutely use emulation, for obvious reasons, debugging and RAM/VRAM viewing/mapping being the obvious ones - I then use a tool provided by jo-engine that does all the tough work of creating an ISO file that I simply burn to my drive-door modified Model 1 NTSC Saturn when I want. It's not ideal. Nor, however, for me, is the Dreamcast's need for either an outdated serial port, or an expensive and rare broadband adapter. Furthermore, the Dreamcast just seems like one of the first systems that seemed extremely close to a PC. I love that I can still fiddle with assembly in very logical ways with the Saturn. I'm not sure if that's the case with the Dreamcast. (The DC, is, incidentally, one of my favourite consoles ever in terms of software!) For the Saturn, there is a new piece of software that can be uploaded to certain times of common/inexpensive Action Replay/Backup RAM carts that allows you to run standard burned CD's. I've meant to buy one for a while now, but sadly I haven't had the time I've wanted to prioritize Saturn dev in the last while due to adulting. :3

TapamN 8y ago
Well, not many DC emulators will run my code anymore, and eventually none will. :P On the DC, I used to use serial port with a USB adapter that manages 384k baud, but upgraded to a BBA several years ago. I really, really, don't like the idea of doing a bunch of development on an emulator, then finding out it doesn't work right on real hardware (either not at all or with unexpectedly terrible performance) and having to figure out what all is going wrong. Doing it all on a real console means you find out immediately where any problems arise. The Dreamcast tries to pretend to be like a PC, but treating it like one will seriously limit performance. The SH-4's terrible cache needs to be babied to get the most out of it, and there's a lot of unusual things you can do with the 3D hardware since it works very differently than other GPUs. You can definitely do assembly on the DC, and it's really important for performance critical code. GCC can't use the SH-4's SIMD instructions effectively, so you have to use at least inline asm or true assembly. I'm not totally sure what you mean by "in very logical ways". I guess optimal SH-4 code doesn't look logical! Rendering-type code is harder on the SH-4 than the SH-2/3 because it's superscalar and FPU instructions have longer latency than ALU instructions. You have to spend more time figuring out how to hide latencies, and software pipelining becomes more important for performance. Optimal SH-4 assembler code ends up much messer looking than optimal SH-2/3 code. For example, normalizing an array of 3D vectors in C, using inline assembly to use the inner product (FIPR) and square root reciprocal (FSRRA) instructions, you'd be lucky to get around 24-28 cycles per vector (it'd be even worse if you used pure vanilla C). But with software pipelined assembly, I can manage 8 cycles per vector. But it's much more complex, not just because it's in assembler. The optimized main loop juggles normalizing 4 vectors at the same time (The loop is 32 cycles, with 4 vectors it averages 8 cycles per vector), and there's code to prepare the loop and exit the loop, and special case code for if there are fewer than 4 vectors to transform. The resulting machine code for the entire asm version is probably around 10 times the simple version. Another example would be transforming a bunch of 4D vectors by a 4x4 matrix. C with inline asm will take about 16 cycles per vector, but optimized pure asm can do 4 cycles. A 3D rendering engine I'm working on for the DC does software vertex shaders by basically copy & pasting optimized assembly loops into a single function and adding a bit of glue code between them.
- 8y ago