Raven. A homemade Atari-like computer

[Atarian Computing]

Oh, and I found this:

bio-888gx0-02_mach64_accelerator_bios_kit.pdf

(5.86 MiB) Downloaded 6 times

And this seems promising:

mach64vbe221.zip

(108.83 KiB) Downloaded 2 times

Excerpt from the TXT:

If your VESA application continues to experience display problems after
loading M64VBE.COM, you should consult the application's documentation
for specific requirements. If the documentation indicates that it
requires memory aperture disabled, single read and write windows or
accelerator CRT parameter you must use the Advanced M64VBE switches
listed below.

Syntax: M64VBE sw1 sw2... (where sw# represent a valid M64VBE switch)

M64VBE SWITCHES:

s - Enable single window implementation. This single window will be
readable as well as writable.
d - Enable dual read and write windows implementation.
3 - Enable 320x200 & 320x240 modes in 8bpp, 15bpp, 16bpp and 24bpp.
VESA mode number 202h, 10dh, 10eh, 10fh are for 320x200 8bpp,
15bpp, 16bpp and 24bpp respectively. Similarly, VESA mode number
212h, 213h, 214h and 215h are for 320x240.
-3 - Disable 320x200 & 320x240 modes.
vw - Set memory aperture to off.
-vw - Set memory aperture to on.
vga - Use standard VGA CRT parameters.
acc - Use accelerator CRT parameters.
u - Unload or remove M64VBE from memory.

Iirc this was an issue with the Mach32?

[agranlund]

Ok, I've been at it with AI. Let's see if it's any good.

Yeah I'm not a fan of spending time analysing and correcting AI "guesses".

To get any kind of sensible correctness out of it you would have to at least feed it the VME -> ISA adapter schematics for which the Mach64 TT driver was designed to work with. Best would also be the code for the GAL on that adapter but it's not open sourced.

However, from the schematics alone it's easy to see it pulls A23 low. With that I think it's safe to assume the driver wouldn't map it above the 8MB mark.

Also good idea would probably be to feed it the driver source, so it wont have to guess where it configures the linear framebuffer location based on what it picked up that some particular Windows or Linux driver that it found has done
It's completely up to the driver where it wants it so there's not much ground truth to be had there.
(The only thing that is set in stone is the default VGA compatible paged framebuffer that cards need to default to until a driver tells it otherwise.
Basically so that any PC since the dawn of time can use it for standard VGA stuff completely driverless)

M64VBE SWITCHES:
3 - Enable 320x200 & 320x240 modes in 8bpp, 15bpp, 16bpp and 24bpp.
Iirc this was an issue with the Mach32?

Yep the card fully supports those modes, and all standard VGA modes.
The Nova Mach32/64 drivers do not though.

These oddball MachXX cards are almost two separate graphics cards frankensteined into one.
One part is VGA compatible based on some old ATI something. This one is unaccelerated so no blitter in 320x200 etc.
The other is a clone of IBM8514A "CAD" card which has the acceleration stuff. This one can only do 640x480 and over.

The Nova MachXX drivers puts these cards in IBM8514A mode, which makes sense of course.
But it does not support switching between that and VGA.

It _can_ be possible by doing a man-in-the-middle attack on the Nova driver.
Detect if a program wants to go 320x200. Poke at the hardware directly to turn off the IBM8514, turn on VGA and set the resolution.
At this point the Nova driver can under no circumstances touch the card because it will still think it's running the IBM8514.

I did some experiments a while ago with that but as far as I remember I wasn't able to get it back to IBM8514 mode and hand it back to Nova reliably afterward.

And then I found the W32i and with that my motivation for messing with my Mach32 disappeared

[agranlund]

Indeed. Rvsound. So there are 3 midi drivers. Did not try the Raven one.
Wavetable installed on the Ess card.

Doom: opl and mpu401 are OK
Scummst: opl ok mpu401 nok (crash total system after 1 note) in DOTT

Many thanks!
That's great to know, I'll test with Scummst here to and see if I can find and fix the issue in rvsound

[agranlund]

Updated the Iksi firmware to support IDE interrupts on the MFP's FDC/ACSI interrupt pin.
https://github.com/agranlund/raven/rele ... .A1.latest

Maybe not super interesting unless you are using a harddisk driver that requires it.
But for the sake of completeness it's nice to now have IDE interrupts that works exactly the same way as on real Ataris.
And it'll be one less thing that needs patching should someone get around to patching up Atari TOS 4.04 or 3.06 to run on Raven

EmuTos and HDDriver does not use IDE interrupts but other drivers might.
For example; Atari TOS does, and so did MagiC (originally, but the Raven version of it does not).

This firmware was tested using a MagiC build that has stock IDE code and my Raven specific "ide-without-interrupts" changes removed.

[agranlund]

Sorry @Atarian Computing , I realise my tone was terrible and I apologise.

I'm happy that you're trying to get the Mach64 working.
I just really don't want to review, test and iterate on AI output but I really should have formulated myself in a more sensible manner. I do apologise.


I'm not hating on AI as such as I do use it myself from time to time. It can be an excellent tool for subject matters one already has a pretty good understanding of so it can be reviewed or sanity checked. A bit like working with and code-reviewing a very junior programmer.

My two different uneducated guesses at the moment would be;
a) Mach64 is not 100% agreeing with Ravens ISA bus implemention, or the speed of it.
This causes vgabios to not run correctly. It also causes the Nova driver to not work correctly.

b) Something is missing in the (very limited) emulated PC environment that the Mach64 depends on.
This causes vgabios to not run correctly. Perhaps even the bad vgabios run puts the card in some kind of bad state, which has a side effect of the Nova driver not working correctly.

Or both.. or something else entirerly

I really think it's a case of someone with card at hand, the interest + time to burn, needing to do a proper debug session.
If it was me I think I would have looked at what the card is doing during vgabios init, so see what PC bios calls it does and what it interacts with on "PC" bus in case something needs fixing or adding to the (very limited) emulated environment.
(but I say that probably mostly because I know that side and I had to do exactly that before to get the S3 cards vgabios to run correctly)

[Atarian Computing]

Sorry @Atarian Computing , I realise my tone was terrible and I apologise.

I actually had to go back and re-read your post, and I couldn't find anything to apologise for.

I'm happy that you're trying to get the Mach64 working.
I just really don't want to review, test and iterate on AI output but I really should have formulated myself in a more sensible manner. I do apologise.

I'm the one to apologise. I wasn't clear with my intentions. I didn't mean to make you do the work. I see the potential for me learning a lot, however futile my attempts might be. I'd need a nudge to get started, that's all.

[Atarian Computing]

Some more testing of CB with EmuTOS. With a minimal setup I can actually get to the desktop but there is no rhyme or reason as to what ACC or PRG will trigger the flood of .f.f.v on the screen. When I loaded NVDI the whole terminal was filled with f.f.f.f. after I saw a flash of the text PANIC or something. Weird. I do have the latest ROM_TOS as well.

Yeah I would try to isolate each individual program if possible.
And then try to flag offending programs to only use ST-RAM.

Same for ACC and CPX but I'm not sure if you can actually flag these or if you just have to avoid ones that can't deal with copyback or are generally incompatible with 68040/60.
And if in doubt, I'll also google for the program and copyback to see if there's any old CT60 wisdom to learn from

XControl doesn't work with copyback cache.
There is a CT60 patch for it, but even with that it still does not work on Raven with copyback cache.
(The patch makes Xcontrol depend on CT60-Bios. Raven does have a partially implemented CT60-bios but something is still amiss and I haven't had a chance to look at it -- for now, you would have to use a different copyback compatible control panel, or use write-through caching if you need Xcontrol)

Gembench also doesn't like copyback, but flagging it to only use ST-RAM will make it happy.

I've mostly done very minimal tests with copyback enabled so it's quite nice you're doing the dirty work here

Ok, I may have something else funky here.

I got to a situation where having CB enabled for TT-RAM would hang with a fairly minimal system until disabling NOVA_COL.ACC. This immediately was fishy because I knew that it worked fine with CB in MiNT. But yet, just the fact of having CB on and booting to EmuTOS would cause this hang and gibberish in the monitor. I thought I'd play along and force it to run in ST-RAM but that wouldn't work either. Changing back to WT allowed me to boot to EmuTOS.

I'll have to investigate my setup further. I've never had these issues until applying the latest update including ROM.

But I definitely am building a compatibility DB of apps for Raven.

[Atarian Computing]

Ok, so I narrowed my CB issue down to EMUDESK.INF. At first I thought it was corrupted and just removed it and everything booted up ok. I then saved a new desktop and same issue. Can anyone verify this with CB on and EMUDESK.INF in C:\ on the latest release? If there are no issues, please share your INF so I can test it on my end.

[Cyprian]

Ok, so I narrowed my CB issue down to EMUDESK.INF. At first I thought it was corrupted and just removed it and everything booted up ok. I then saved a new desktop and same issue. Can anyone verify this with CB on and EMUDESK.INF in C:\ on the latest release? If there are no issues, please share your INF so I can test it on my end.

could be related to the cache state in TOS/EMUTOS inf file?
https://www.atari-forum.com/viewtopic.p ... 10#p441610

Code: Select all

Video settings (some features not available on some versions of TOS)
#E PR BR xx OP LD CM xx xx xx...

   OP = Other configuration parmaters
     bit 1: Cache
        0 = off                  1 = on

Setup from TT and EmuTOS:

Cache OFF:

Code: Select all

#E 7A E0 FF 02 08 

Cache ON:

Code: Select all

#E 7A E0 FF 02 00 

[Atarian Computing]

Ok, so I narrowed my CB issue down to EMUDESK.INF. At first I thought it was corrupted and just removed it and everything booted up ok. I then saved a new desktop and same issue. Can anyone verify this with CB on and EMUDESK.INF in C:\ on the latest release? If there are no issues, please share your INF so I can test it on my end.

could be related to the cache state in TOS/EMUTOS inf file?
https://www.atari-forum.com/viewtopic.p ... 10#p441610

Code: Select all

Video settings (some features not available on some versions of TOS)
#E PR BR xx OP LD CM xx xx xx...

   OP = Other configuration parmaters
     bit 1: Cache
        0 = off                  1 = on

Setup from TT and EmuTOS:

Cache OFF:

Code: Select all

#E 7A E0 FF 02 08 

Cache ON:

Code: Select all

#E 7A E0 FF 02 00 

Thanks. But shouldn't it be:

Cache OFF:

Code: Select all

#E 7A E0 FF 00 

Cache ON:

Code: Select all

#E 7A E0 FF 02 

If so, it was set to 02, aka on. According to Thorsten's diagram, the following byte is some line-doubling setting

Disabling it made no difference regarding hanging. Funny thing is, if I had CB on and deleted the EMUDESK.INF file and booted to a clean desktop, I could load any INF file without any problems. So bizarre...