An early release of BadMooD (Doom game) for the 68060 CPU was released last night. General info is in the bmalph02.zip file.It's in the downloads area here: http://devilsdoorbell.com

I wonder if anyone can test with SuperVidel please? As far as I know there isn't any specific SV code in the build. [yet]There are minor bugs (like a random freezing of the screen) and it's limited currently to 12 FPS, but '060 should push this much higher in a later release.

viking272 wrote:I wonder if anyone can test with SuperVidel please? As far as I know there isn't any specific SV code in the build. [yet]

I just ran it on SuperVidel. Almost works. The splitscreen effect for the status panel doesn't work. I'm not sure if SuperVidel allows HBL/Timer-B HBL at all, or if it's due to that I havn't done the solder install (which uses sync signals from the motherboard).

Plotting pixels direct to SV-RAM is not a good idea, there's a big penalty for many small writes.At least when doing 8-bit/pixel tests, this method was much faster than rendering directly to SV-RAM.

Oh, I filmed BadMooD on SuperVidel with my phone. I thought there was a bug with strafe-mode being stuck, but it was just me not realising that you had to use the mouse! So the movement in the video is pretty silly. But when thinking of it, not sure how I should have controlled it with mouse+keyboard and still hold the phone for filming. I need a third arm.

Yeah, I think their approach is more sane than trying to stick a Radeon to a PCI-bus like some other solution. It's a lot of more work to do of course, but the end result is worth it. If one's after quick Open GL on the Atari, then maybe not, but for the rest, I think SuperVidel got it right.

dml wrote:I should be able to replace the floor texturing with a CPU-friendly version for 060 and then it should work safely plotting to a fastram framebuffer and copying it over as you suggest. When this happens I'll raise the FPS cap back to 25 (or 35?) to see what happens.

35 Hz game logic sounds good for a 060, I don't think it has a problem traversing that junk-code But doing different code-paths for rendering on 060 sounds like a big job, perhaps best spend the time to get it ready for 030 machines before poking into that stuff, after all, BadMooD is really a great showcase for standard Falcon 030.

evil wrote:Yeah, I think their approach is more sane than trying to stick a Radeon to a PCI-bus like some other solution. It's a lot of more work to do of course, but the end result is worth it. If one's after quick Open GL on the Atari, then maybe not, but for the rest, I think SuperVidel got it right.

While I do like OpenGL, it does remove a lot of the fun from that side of things

evil wrote:35 Hz game logic sounds good for a 060, I don't think it has a problem traversing that junk-code But doing different code-paths for rendering on 060 sounds like a big job, perhaps best spend the time to get it ready for 030 machines before poking into that stuff, after all, BadMooD is really a great showcase for standard Falcon 030.

I definitely won't spend time doing 060 optimized code - at most making it understand different kinds of RAM (e.g. SV RAM). In fact BM had 'fastram buffering' even in the old versions - because I did the same optimization for AB40 (build the framebuffer in fastram, then copy with move16). Of course the importance of this is now much greater on SV but it means I probably don't have to do a lot of work

Note: It needs a CPU-based floor texturing option anyway, to make it work safely with other accelerators so I don't count it as 060 code, even if it will help there much more than it will for other kinds of upgrade.

evil wrote:I just ran it on SuperVidel. Almost works. The splitscreen effect for the status panel doesn't work. I'm not sure if SuperVidel allows HBL/Timer-B HBL at all, or if it's due to that I havn't done the solder install (which uses sync signals from the motherboard).

It does. Basically the VIDEL is still generating these interrupts, so if you did the soldered install, these interrupts should occur at the right times / locations. The scenario will be slightly funny in SV-specific resolutions however, because the VIDEL may still be generating the VBL and HBL:s, but they'll have no relation to the SV screen output. There's simply nothing to do about that unless people want to solder 500000 wires to their motherboard and replace the on-board chipset.

shoggoth wrote:dml:What exactly happens in your splitscreen code?Does the 160x200 option use "wide pixels in hardware"? (awesome in such case, because that means the SuperVidel is actually compatible with this, and I don't think any of us tested that before!).

The 'splitscreen' timerb sets the video address counters - moves physbase for the next line onwards until the next VBL. It also resets line doubling on RGB, if it was enabled on the VBL. So you can have low-res play area and high res status bar on RGB.

I did try to 'splitscreen' the horizontal 'fat pixel' state at one point on VGA, but found that doing so required other register changes which resulted in the VGA wanting to re-sync on the next line, and my monitor went dark with much whining. It might be worth trying again with more time to experiment but I gave up pretty quickly.

So the current version touches only the display address and the double line flag.

Hardware fat pixels on VGA will only work in fullscreen mode with no status bar. There's a bag of logic in the window resize code to figure out which hardware modes are compatible with statusbar/monitor/window combinations and which need filled in with software doubling...

Note: The raster does not attempt any kind of hardsync with VIDEL (!), but does implement a 'softer' sync with MFP timerb data, inserting 1 scan of padding time before displaying data. If pixels are displayed on the transition line they corrupt - but at least the status bar doesn't jump when you move the mouse etc. I haven't quite finished tidying that side of things - there should be an empty line immediately above the SB and there isn't.

shoggoth wrote:Does the 160x200 option use "wide pixels in hardware"? (awesome in such case, because that means the SuperVidel is actually compatible with this, and I don't think any of us tested that before!).

I just noticed I probably didn't answer your question

On VGA only, and in fullscreen only - yes it uses wide pixels in hardware. In all other configurations it is stuck with software fat pixels.

On RGB it can use line doubling at any time, including with status bar, windowed/fullscreen and statusbar remains un-doubled.

BTW Hatari does something different with physbase updates too - it seems to pick up the address on a new frame just *before* the VBL interrupt, so attempting to set the register in the VBL routine is already too late. On real HW it's not observed until the display begins, or some time deeper into VBL period so you can set physbase on the interrupt and it gets picked up.

Not exactly related - but display address stuff seems to be a bit of a compatibility fuzzy area on Falcon

(TBH the Hatari issue seems to be more of a hazard than splitscreen stuff - likely to be more common for a start and less obvious what's wrong)

Last edited by dml on Thu Jan 30, 2014 10:49 am, edited 1 time in total.

mikro wrote:This is not the case anymore. Slight change to the PMMU tree results in super fast byte access which happens to be the fastest, too PeP is working on new version of his drivers.

New driver is sort of ready, at least for beta testing. This feature is highly experimental and I don't think it should be released into the wild before some degree of testing... remember to always wear goggles + helmet.