Raven. A homemade Atari-like computer

[PhilC]

I dont know what sorcery Anders' drivers may perform, but providing the standard IBM VGA registers are used, it should be just the video buffer base address that needs changing ($a000<>$c000 or something like that).

The Raven uses the Nova drivers at the mo, do is limited to the ET4Ks and Mach32&64 at the mo. The W32 s are hard to get hard of in ISA only, the cheapest on eBay being around £150.

[mrbombermillzy]

Well really Anders should be able to elaborate here, as he will know if something has been done differently.

But it may just be the framebuffer base address that needs changing; something that can be done with a hex editor, a decompiled/source version of the video driver and a good guess at what the current<>required screen address is. :)

[agranlund]

And any other plans for Raven? I'm likely to takeine to Cyber legends this year all being well.

Mostly minor things for Raven.A2. I hadn't touched its schematics in a long while but I figure it would be nice having a second board so that one can be cased and the other one loose for easy access to experiment/modify.
So I've started playing with the A2 in kicad a bit again.

The kicad files aren't up to date but the readme is almost current with what I've done / am doing:
https://github.com/agranlund/raven/tree ... /raven/a2

It's a pretty small incremental update mostly driven by me wanting a second board.
The only bigger change is probably the Eiffel change, and ethernet too (once the software part is done, that is)
I've had it in my head to put a VS1053 dsp on the next Raven board since I built the previous one, but I don't know for sure if it will make it to this version yet. It's the first on the chopping block for this version if there's an issue with spare time vs scope vs when I want this board done :)

[PhilC]

@agranlund I thought you might have put an rtl8019 on it as they are cheap as chips at the mo as well.

Can I make a suggestion? Moving the two nuggets near the 68150 away a little, to give more room for my dodgy soldering :lol:

[exxos]

The only bigger change is probably the Eiffel change, and ethernet too (once the software part is done, that is)

Are you "Fixing" the drivers for ethernet as stuff at the moment hangs off the cartridge port and very "hacky" normally. I ask as i've wanted to put LAN onto a future H5 build (or do a proper addon for the 68K bus) but the software side of it all is beyond me to fix. I mean putting a chip on a bus is almost simple, its the rest which is the problem :P

[agranlund]

The Raven uses the Nova drivers at the mo, do is limited to the ET4Ks and Mach32&64 at the mo. The W32 s are hard to get hard of in ISA only, the cheapest on eBay being around £150.

Yep, in practice you really want to use an ET4K or Mach with the Nova driver.
Other VGA compatible cards will give you a 640x480 mono screen (go into the bios settings and deselect the nova driver)
That's pretty much the state of things right now.


The ideas for some kind of non-nova driver framework was to support most cards in their basic form. And an easy-ish way to implement device specific drivers where you could plug away at implementing the card specific stuff to get the most out of it.

Each driver wouldn't need to provide that much in terms of functionality. It's mostly about querying modes, settings modes, save/restore state, providing the framebuffer. And then hardware acceleration functions too would be custom for each driver of course.
Similar in thinking to VESA, or any of old DOS or even Linux gfx driver frameworks from old.

With the caveat for acceleration, a device driver wouldn't need to implement any primitive drawing since it's all the same regardless of card. fVDI or NVDI can take care of that with a single VDI driver part that talks to the driver framework which delegates to the specific device driver -- or something like that was the thinking anyway.

The framework would aid making device drivers by supplying basic VGA support functions, which is also helped by being able to directly execute x86 vgabios. I had VESA feature detection and calls there too to some degree, but keeping in mind that the cards of this era are VESA1.2 at best and some cards don't even have VESA bios implemented in rom.

And while VESA1.2 provides a standard for mode numbers, linear modes was not added to the standard until VESA2.0 so the ones exposed are bank-switched modes.
This means you wouldn't want to use them for anything but placeholder until card specific code was written to set a linear mode.

(Bank switching is terrible and slow, especially so on Atari since VDI does not know of that concept and can optimise for them like Windows could. I did have bank-switched mode running here in my wip stuff by using the MMU to provide a virtual linear space with auto bank-switch on access like how you normally would for virtual memory. This was fun to do, and more so than any practical use for it)

For user-facing API I thought it would provide a nova-compatible interface so existing programs wouldn't need to do anything special.
As well as an xbios API a'la Falcon, same as how it's done on SuperVidel and V4SA.

That was my thinking anyway. But it's only in my head + disorganised experimentation code which means it'll likely not be a practical option in a long while or maybe more realistic, ever :)
It's mostly been for the fun of playing around with gfxcards more so than trying to replace Nova which is already there and works well.

And while doing so I think it makes sense designing for the common stuff, which is 90% of the code, to be common and so that the relatively small parts which are hardware specific are the only things one would need to care about when deciding to play around with some other card.

Wow, that turned long, sorry for the wall of text :)

[PhilC]

Wow, that turned long, sorry for the wall of text :)

Posting on my phone, it took me ages to delete all that text :lol:

But joking aside I'm glad you did post what you did as it appears I have similar ideas where VGA cards are concerned. I just have to relearn all the stuff id forgotten from about 30 years ago.

[agranlund]

@agranlund I thought you might have put an rtl8019 on it as they are cheap as chips at the mo as well.

Can I make a suggestion? Moving the two nuggets near the 68150 away a little, to give more room for my dodgy soldering :lol:

That's a great suggestion, thanks! It's quite cramped there for little reason :)

[agranlund]

Yay! Motherboard temperature sensor is now working well with the Eiffel replacement -- which I'm now calling CKBD, as in IBKD with Chinese microcontroller :)

I've been dragging my feet about it but I'll have to get the board out of the case one of these days to do the code for reading the CPU temperature as well, since it'll require soldering a patch wire from cpu to ckbd.
And a wire that should enable me to do software controlled power-off too while at it.

[PhilC]

@agranlund I'm wanting to start experimenting with programming the Raven, what are you using for your programming environment? Do you use the Raven now for programming or something like VSCode?