Raven. A homemade Atari-like computer

[dml]

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?

Yep I'm afraid I don't know the magnitude of the error or if it's confined to e.g. the multiplier only. But there is some kind of randomness creeping into results at high OC levels on my CPU.

It could be the LSBs or the rounding bits or something like that which don't show up much in real world stuff. I'll need to look at it a bit more closely. All I can say is that the computed results, when treated as binary IEEE encodings and hash-summed over a series of operations, isn't the same between runs (and with the initial FPCR state and conditions etc. always known at the start of the test).

I also don't see any actual instability, even if I haven't been running FPU intensive stuff yet - but I do have plans to use FPU soon :)

[Steve]

I've always been concerned with how people like to overclock the 060 to 90+ MHz, for such a rare and expensive CPU I've never thought it a good idea. Why would you get a classic car engine and thrash it to the highest RPMs is my analogy, I suppose the FPU test really is the ultimate when showing the true safe overclocks.

[agranlund]

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

Hi! Oh that's really hard to say since I haven't given it that much thought -- and I haven't been in that much of a rush, even though I do regularly feel that I could do with having two board myself.

I had a bit of a sprint in Kicad a while ago and then decided to let it rest for a bit. Partly to get fresh eyes before finalising and checking it over before ordering, and partly to decide if another larger change should go to this board or back to the ideas box for the future.
But maybe mostly because I wanted to do some programming instead.

The board is near enough there but knowing myself I can't commit to when I'll go back to working on it, so if it was me I _think_ I'd go for the current version? I'm easily distracted and jump a bit all over the place :)

--Anders

[LarryL]

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

The board is near enough there but knowing myself I can't commit to when I'll go back to working on it, so if it was me I _think_ I'd go for the current version? I'm easily distracted and jump a bit all over the place :)

Thanks Anders,
I can totally understand this - I do experience this myself, too :-) many parallel projects and jumping from one to the other…

Lets see, what the others think, but I doubt they are in a rush

Take your time - when it is ready, it is ready
…and it surely will be great :-)

Cheers
Michael

[TheNameOfTheGame]

Yes, no hurry, but I am waiting for A2 version to build one. Enjoying reading about everyone's current builds though.

[Mikerochip]

Take your time - when it is ready, it is ready
…and it surely will be great :-)

You've a board to ready too @LarryL :D

Yes, no hurry, but I am waiting for A2 version to build one. Enjoying reading about everyone's current builds though.

ONE OF US! ONE OF US!

@agranlund Can I just use a ROM programmer, to program the ICs individually, instead of using the ROM programmer PCB.
(Is it interleaved or location specific?)
I'm just curious.
I've (almost) built two rom simm programmers :D I'm just wondering if I can use the XGecu T48 to program them, before the simms sockets arrive!

[agranlund]

@Mikerochip yep, should be possible. Each 32bit dword of the rom is interleaved across the four chips.
(I think the XGecu software has options to de-interleave when loading a binary, otherwise you could probably find or make a splitter tool)

[agranlund]

And now my WD90C31 card can suddenly do this :)
The card has hardware acceleration but the driver isn't capable of using any such stuff yet.
But it sure would be nice to make use of the blitter to get more sensible blit and scrolling performance.

IMG_5128.jpg

I'm testing a CirrusLogic and OAK card in parallel and they're also going into SuperVGA but have more kinks to work out.
It's mostly for me to have more than one low-level "client" for the base framework as I find that helps in getting the design good-ish, and to have more than one example should someone find the urge to implement a driver for some other card.

I do plan on trying to support auto-bankswitch for the older cards which only have banked SVGA modes. A bit similar to virtual memory in that the driver would provide a (virtual) linear framebuffer as required by VDI, and then switch in correct bank behind the scenes on access violations.
Not sure how useful that is in real life since cards of that age are quite slow to begin with, but fun for me.

[PhilC]

@agranlund that's good news. I was going to try and disassemble the vdi drivers at some point and have a go at doing drivers.

I've got a cl-gd5429 and an S3 board to play with at some point.

I shall be looking on with interest on this one.

[agranlund]

@agranlund that's good news. I was going to try and disassemble the vdi drivers at some point and have a go at doing drivers.

I recon I'll put the existing stuff on github during next week or so. I think it should make it trivial to add support for more cards (as trivial as graphics card drivers can be that is :lol:)

The middle-layer framework, which sits between STA_VDI and card specific drivers, deals with all the common boilerplate stuff so each individual driver ends up quite small. The WDC and Cirrus ones are both ~300 lines of C code and will be submitted as work-in-progress examples one can base new drivers off.
These are both leveraging the fact that we have vgabios, making the situation quite similar to SVGA in MS-DOS.

When acceleration becomes a thing the idea is that individual driver can supply an optional blit() callback of sort that does only the hardware specific stuff. To be called by that middle layer as appropriate.


The thing can be compiled to include only one specific card driver (+generic vga fallback, this is always there) or to include and probe for all of them. I haven't really decided how I want to package this up for raven yet.
Right now I'm building a monolithic one that auto detects WDC and Cirrus for SVGA support, or falls back to the failsafe VGA-only core.