Raven. A homemade Atari-like computer

[LarryL]

Hi,

@agranlund - how is the timeline for the A2 version of the board?
any plans to release this anyway soon?

Me and a small group of German fellows are planning to start a raven build in autumn - yeah, finally :-)
And I am wondering if we should wait for the A2, or simply start with A1 and use the available tweaks and upgrades
But looking at the Github and the info on the A2, esp the integrated ethernet option, the included Eiffel-replacement by USB and the "not byteswapped" IDE, waiting a bit might be wise...

Cheers
Michael

[agranlund]

A new release package:
https://github.com/agranlund/raven/rele ... .A1.latest

If cherry picking, you'll need to update the rom, rvbios, rvnova and the c:\nova folder.
I would update the simm programmer too even though it's not strictly necessary.

Changes are mainly:

• Rom layout changes and size optimisations

• Rom now has a configspace area which is kept intact even when flashing updates

• Added generic Nova VGA driver

The generic nova driver is an early work in progress and experimental at best.
Note that it's VGA _only_ at this point and does not yet support SVGA or VESA.
Additionally, 16 color planar is quite slow compared to 8bpp+ chunky modes but still a lot nicer than being restricted to mono only.

Known bugs:
There is an issue with running 256 color games from a 16 color desktop, but works when desktop is in 2 color mode.

Tested with the following cards:
- S3 86C801C : ok
- OAK OTI087 : ok
- WDC WD90C31 : ok
- Cirrus Logic GD5426 : ok
- Trident TVGA8900D : fails at vgabios

These are all pretty good cards and I'm curious if the cheap stuff works so I think I'll have to visit ebay for some low-end unwanted ones.
(yes, even that exact model Trident is actually good, for a Trident :) )

[alexh]

I have some ideas of how I'd like to structure support for optional accelerant drivers. Most/all of the late ISA cards have hardware blitter and I suspect it would be a great deal of fun to try and get one of them working sometime later on.

There is a very knowledgeable guy in the Amiga community called Thomas Richter, he wrote the majority of gfx card accelerated drivers for the Amiga (equivalent of VDI?) Picasso96. It's only a small subset of VGA chipsets but he's very approachable and super knowledgeable. Assuming you wanted to refer to someone.

https://eab.abime.net/showthread.php?t=105576

[PhilC]

Great update, thanks very much @agranlund

I think you've tested all the VGA cards I've got except some other Cirrus Labs ones.

[agranlund]

There is a very knowledgeable guy in the Amiga community called Thomas Richter, he wrote the majority of gfx card accelerated drivers for the Amiga (equivalent of VDI?) Picasso96. It's only a small subset of VGA chipsets but he's very approachable and super knowledgeable. Assuming you wanted to refer to someone.

Oh nice, thank you for that tip! I'll definitely want to reach out to him :)

[dml]

Updated most things today to the latest:
- Nessi
- ROM programmer
- ROM
- Software

...everything appears to still work. The first boot had it stuck on the Atari logo with no further progress but on a second try and entering the bios, rebooting, it worked.

Will try the other cards again with the new VGA BIOS support and report back later.

[edit]

While I'm here, I found this article on reviving JTAG-locked ATF150x chips. i.e. the used chips which had the JTAG pins reallocated as I/O. Since it involves applying 12v to a pin, it's not something we would be trying in-system on the Raven but it might work if done on a prototype board.

https://www.hackup.net/2020/01/erasing- ... 1504-cpld/

[luciodra]

Great !
Thank you.

[dml]

Interesting....

So while my Raven appears stable in normal use at 96MHz and the CPU isn't getting overly hot, it is failing my own FPU testsuite.

At first I thought the test was not working properly on the 060, against the pre-recorded 68060 expected results set - but after a bit of experimentation, I noticed the computed hashes on the failing test cases were different on every run.

I switched back to the 40MHz oscillator (80MHz CPU) and the test passes cleanly, with the correct hash results.

So I suspect 96MHz OC is causing the internal FPU to quietly fail. Specifically the float multiplier unit and some of the transcendental functions. Other operations pass.


Maybe some other Raven builders are interested in running the test themselves and see what happens? You'll need to copy EXPECT60.DAT to replace the default EXPECT.DAT because the 060 computed result bitpatterns are not identical to a 68882, which is the default set.

https://www.leonik.net/dml/files/fput141.zip


For a longer running burn-in test, there's an alternate version. Mostly the same tests but rebalanced to make the chip fail sooner when overclocked and repeating in a loop.... this will use the same EXPECT.DAT file as input.

https://www.leonik.net/dml/files/fpub141.zip

[agranlund]

Updated release with an updated vga driver.

Fixed runtime mode switching so now one is able to do this regardless of graphics card model (*)
(*) in theory.. I know at least one card fails during vgabios initialisation and I'm sure there are others



The next step will be card specific SVGA support for nicer resolutions.
But I'll probably switch back to working on the SuperIO driver again before that.

[agranlund]

Maybe some other Raven builders are interested in running the test themselves and see what happens?

I'm getting exactly the same results as you observed in your machine with 40 and 48mhz oscillators.
Would be interesting to know the magnitude of the error compared to expected result, or if they're complete garbage.

I only have three programs I know for sure is using the FPU and they appear to work fine but it sounds like they technically aren't then. Perhaps the error is not significant enough to matter for non-science stuff?

Quake, makes heavy use of FPU all over the place
Doom, for muls and divs if FPU is available
mxPlay, minimal use for the GUI sliders.