Raven. A homemade Atari-like computer

[agranlund]

In an effort to accelerate some more VDI but with as little effort as possible I tested the lazy approach of hooking STA_VDI's internal line-drawer it's using when rasterizing primitives such as circles, polygons and so on. Basically calling my drivers generic blitter fillrect instead to make a line.

The result was slightly disappointing.
Setup cost ends up stealing a huge chunk of the gain, particulary when doing short lines as in the v_circle test.
v_ellpie and v_pieslice are both drawing quite long lines so while it's all very unoptimal, the setup penalty doesn't hurt as much.

I think the proper non-lazy solutions would be to implement dedicated linestrip support in the driver.
So instead of paying a setup penalty per line you'd get one per batch of lines.
Was planning on doing that anyway but for the purpose of using it directly from games (hardware assisted triangles), but VDI could in theory also use that by hooking it in a manner which takes a bit more effort.

One nice thing that came out of this experiment was it had me revisit the drivers blit function where I found some obvious things to optimise in regards to call overhead. v_bar in particular shows the result of that. blitting too to some degree but the slowest path was fillrect setup.

IMG_5571.jpeg

[agranlund]

I found an old Mach32 benchmark and comparing against that makes me less disappointed about the lazy vdi primitive accel implementation.
They're actually in the ballpark on many of the things at least.

IMG_5572.jpeg

[agranlund]

And to further reduce driver overhead I went ahead trying out the memory-mapped I/O feature of Cirrus GD5429/34.
Made a difference for sure being able to replacing slow ISA IO access with ISA MEM access.

IMG_5573.jpeg

IMG_5574.jpeg

[PhilC]

Wow, will have to fit a second CPU just to keep up at this rate

[exxos]

I think GB6 breaks when you get to 9999% :P

[agranlund]

I think GB6 breaks when you get to 9999% :P

This is my goal! :lol:

[Mikerochip]

@agranlund !

I can't remember if I mentioned this already...

Would it be feasable to fit an STFM video shifter to the ISA bus...
not for video out.
Well, maybe for pre-boot video out?
Can one be stitched in on the isa bus as is?
It only uses data and address lines, then, four other pins. Are they all present on the ISA bus? If not, we can add a flywire to them...
Lots of Amiga software, where there's an accelerator + video fitted, work like that, I guess.
Inbuilt standard video chipset to handle legacy apps, that write directly to it, but, for everything else, normal fvdi drivers etc.

How the Voodoo2 etc work, got me thinking.
As usual, I've more ideas than talent :D

What if you fitted a video shifter. Sort of a pre-boot video... OK, not very useful you say...

How about using it to run ST software.
Can you isolate (or, at least, keep track of) the memory the shifter writes to, and, display it in a window?
And/Or. Is that useful, at all, for, say, your ST emulation?

If your emulator is running via a real shifter, real YM, and real 68000 instructions...

Good idea? Bad idea? Just crazy rambling at night?? You decide :P

[stephen_usher]

@Mikerochip I'm afraid using the original Shifter would be effectively impossible. It's only part of a tightly integrated system in the ST and it requires the MMU to work at all and the MMU to control access to the RAM. The closest you could possibly get would be an ISA card with on-board dual ported RAM and the equivalent of the MMU. Of course this ISA RAM would be in a different location to the ST so it wouldn't be backwards compatible with the ST anyway.

So, basically, no, it's not possible in the way that envisage.

[agranlund]

@stephen_usher said it better but I'll post this thing I typed up anyway :D


Don't know about crazy, or maybe we're both crazy :D
I've had similar ramblings with myself from time to time.
Even wondering if the "Graphics Gremlin" opensource and fgpa based MDA/CGA card could be rewritten to do Atari screen modes.

But I always end up with the same conclusion:
This is a solution looking for a problem rather than the opposite way around.


* Boot
No need, you have an Atari mono compatible display active from bootrom and forward.
The reason you don't see the EmuTOS version string and then its splash screen/menu is because I've disabled them in EmuTOS builds for Raven.

* Castaway
The emulator is already frame throttling to prevent it from running too fast.
It could potentially get faster conversion routine running in 16 color planar VGA but because of the above I didn't bother yet.

* Software poking directly at Shifter
If they do that, they probably need to run through Castaway anyway for other hardware-banging reasons, on top of general 68060 incompatibilities.


But lets say we find and really want to use some application that is OS friendly but needs ST-Low or ST-Medium to display correctly (ie; not necessarily shifter _hardware_ but assumes the screenmode)
I always end back up thinking a TSR doing Atari 16 color planar -> VGA 16 color planar behind the scene is probably the best route in those cases.
(same concept as mono emulators for Atari ST with color monitors)

Having some kind of Shifter graphicscard would still require support software in terms of a TSR doing pretty complex mmu-tricks behind the scenes, if you wanted old applications that weren't written specifically for that card to work.
As mentioned. Such graphicscard would need some logic that feed the shifter with the data.
That data would have to live in some dedicated ram.
Hence the complicated bit of software (that I'm not sure is even possible) in the background to make that appear as ST-RAM - to make this theoretical program that is somehow OS and 060 friendly apart from only the shifter "just work". This theoretical program would also have to be important enough, and benefit enough, to make it worth it for someone to invent this instead of just running said program in Castaway :)

[agranlund]

How the Voodoo2 etc work, got me thinking.

That Voodoo talk put ideas in my head too.. I've managed to evict them for now, hoping they don't come back :D

But in essence.. the Playstation1 GPU, particularly the one in the last smaller model, doesn't need that much in terms of external components.
Could make a pretty cool graphicscard :D