exxos's Atari, Amiga & retro forum

Humm... it surely wont help that apparently I've only been tagging up 4MB of ISA memory space, starting at ISA:0 And then I was assuming the Mach64 driver placed vram at ISA:4-8 :)
Which, even if the guesstimated memory map is correct, could be bad news with that region having incorrect cache flags set.
I don't think fixing this will solve the entire Mach64 mystery, certainly not for the bios part, but it won't hurt so I'll tag up the entire 16MB.

edit:
Latest release zip has an updated rom which now maps in the entire 16MB isa-ram range.
@redpixel , might be worth testing the Mach64 the same way as before again, letting the Mach64 nova driver activate regardless if you're getting a picture directly from bios or not.
After this, I don't think I can do a whole lot without such card in my machine.

As I looked at the old bootup mmu code again I notice that the previously unmapped ISA range would have all pointed at a single "dummy" page in system ram.
So even if I had guessed the Mach64 drivers memmap correctly all CPU access would have ended up to that dummy page rather than gfxcard memory.

agranlund wrote: 15 Dec 2025 10:10 Latest release zip has an updated rom which now maps in the entire 16MB isa-ram range.
@redpixel , might be worth testing the Mach64 the same way as before again, letting the Mach64 nova driver activate regardless if you're getting a picture directly from bios or not.
After this, I don't think I can do a whole lot without such card in my machine.

You definitely made something better! This is with the Mach64:


It seems to be really sensitive. I saw some minor graphical corruption and one start-up freeze (when loading NOVA) with the Mach32, so I tried switching to the 40 MHz oscillator (instead of 48 MHz which I was using previously). When I used the 40 MHz oscillator the Mach64 hung in the InitVga stage (when trying to execute the VGA BIOS), both with X1 and X2 (not sure if that affects the timing of ISA bus accesses). The Mach32 seemed to work OK with the 40 MHz oscillator, although I haven't run any type of benchmarking or so (only boot-ups).

When I switched back to the 48 MHz oscillator and X1 mode the Mach64 manages to "run" the VGA BIOS (or at least InitVga returns), but it still gives the 8-bit vgamem message and no further print-outs and the screen stays black. After NOVA initialisation you actually see something (at 1024x768x8). Redraw seems to be non-functional though and there are some artifacts.

If you want I can of course send you my board, or maybe I could try to do some debugging on my own if I manage to get up-to-speed with how to build the ROM etc. :) I don't have anywhere near your programming skills or knowledge of the ISA bus, but it would be a fun challenge.

Wrong bird.. shouldn't it be RaveAMP :lol:

redpixel wrote: 15 Dec 2025 20:03 You definitely made something better! This is with the Mach64:

Haha, not sure if it's better than nothing :)
But something's on the right track at least.

Thanks for the offer about sending the card over. I think at the moment that would just entice me to spend too much Christmas vacation on that stuff but perhaps at some later date unless you've already fixed it by then :)

@agranlund: do you have api documentation for FalcAmp plugins maybe?

nokturnal wrote: 16 Dec 2025 17:32 @agranlund: do you have api documentation for FalcAmp plugins maybe?

Not really documentation as such but the FalcAMP v1.20 full package comes with sourcecode for a mod plugin that can be used as a kind of api reference: http://deunstg.free.fr/sct1/falcamp/download/index.html

@agranlund: thanks, I've missed it somehow. Original release docs mentioned that api info is 'on demand', so I thought that maybe you have requested one. But it doesn't matter..

Yesterday I tried formatting the SD-IDE and BS and starting the whole procedure from scratch by reinstalling everything, but I keep getting errors. The doubt that I damaged something during my attempts is very high. With the CF-IDE without BS everything works perfectly, except for the YM audio. With the current update I was hoping that the issues with the ISA cards would be resolved, but they are still there. For those who don't remember, it concerns the 16-bit cards that need to be taped (with adhesive tape) to work properly...

luciodra wrote: 17 Dec 2025 12:48 Yesterday I tried formatting the SD-IDE and BS and starting the whole procedure from scratch by reinstalling everything, but I keep getting errors. The doubt that I damaged something during my attempts is very high. With the CF-IDE without BS everything works perfectly, except for the YM audio.

Since you have two different variables in place it cannot be said for certain if the byteswap adapter is contributing to the problem or if it's the SD vs CF adapter (or a certain combination of the two). I think that I would have tested the four permutations to narrow that down;
- SD, with byteswap adapter
- SD, no byteswap adapter
- CF, with byteswap adapter
- CF, no byteswap adapter


I'm wondering if the three issues are somehow related, or indeed three separate issues. YM, IDE, 16-bit part of ISA
However, since [cfcard, no byteswap adapter] works but you still don't have ym. I'm not convinced those two issues are related.

For YM, you've got some control signals going to it from Iksi (as well as data bus D31-D24).
I would have measured the clock to verify a 2mhz signal there, and perhaps also looked for activity on the control signals.
but without equipment I think maybe I would at some point resort to testing a different ATF22V10 in case some of those three pins are dead.

(but there could be so many reasons, and ideally I would scope everything else that goes in/out of YM before doing so unless I happened to have a spare one of those laying around)

luciodra wrote: 17 Dec 2025 12:48 With the current update I was hoping that the issues with the ISA cards would be resolved, but they are still there. For those who don't remember, it concerns the 16-bit cards that need to be taped (with adhesive tape) to work properly...

I really think this is some kind of hardware issue on your particular board. Or the card, unless you tested different 16bit cards with same result?
Could any of the signals that connect to the 16bit side of the isa slots be shorted against something or a case of bad / not-connected?
(not necessarily right at either of the 4 slots but anywhere else they are routed to as well)

I have a bit of work to do on the Raven for Christmas. :lol: