Raven. A homemade Atari-like computer

[agranlund]

Hurray!

Yesterday I was 100% convinced I had wired up the ISA interrupt lines wrong..
So I made a note about changing for next revision and try to figure out if there's a sensible way to patch up the A1 version.

Today... it looks like it's fine after all. phew!
(I hope I'm not jinxing it, I've only verified with a soundblaster so far)


I realized I never actually tested ISA interrupts until now that I wanted to start using them for sound related stuff.
(and in the future, to improve performance of the network card driver)

So I added an interrupt dispatcher and a user API to ISA_BIOS but absolutely nothing was working as expected.
It turned out I had only written dodgy code again :lol:

Now, in my test program, the soundblaster is firing off interrupts on ISA-IRQ5. The secondary MFP detects them and ISA_BIOS is calling out to everyone who has registered interest in that particular ISA IRQ number.

isa_interrupts.png

And I finally got a good reason to try out the ISA extender I got a while back.
Debug headers for the entire isa bus are quite handy!

isa_extender.jpg

[luciodra]

This is a good news !!!

[frank.lukas]

What about use the 8bit ISA USB Controller, Annadue ISA-zu-USB card ...?

[PhilC]

Nice update. Not had time to do anything with my Raven lately but hope to be able to soon.

[agranlund]

Minor update which probably wont effect many.

Code: Select all

20251214:
  rom:      support EmuTOS Shutdown feature (when ckbd is present)
  rom:      removed nova driver specific pmmu mapping
  rvnova:   add nova driver specific pmmu mapping
  isa_bios: support isa-interrupt callbacks

As part of moving the Nova driver specific VME->ISA mappings from bootrom to rvnova.prg I took a stab at guessing what the Mach64 driver wants.

If someone has a Mach64 card then it could be worth giving it a go in the odd chance I actually guessed correctly..
I'd love to hear if it works or not since I don't have one of those to test with myself.


So I don't actually know for sure where the Mach64 driver is setting up vram in ISA space nor where that is in VME space, so this is mostly some kind of best-guess based on how the VME adapter schematic looks, and only very few minutes with the driver disassembly.

Based on that, as well as what the Mach32 driver is doing, I'm working with the theory that the driver is treating FEC00000 as start of vram in VME space and (ISA_BASE + 0x00400000) as the equivalent in ISA space.
Which could be a completely wrong guess so if someone actually knows then feel free to share :)

Code: Select all

VME 0xFE900000 -> ISA i/o base
VME 0xFEC00000 -> ISA ram base + 0x00400000
VME 0xFED00000 -> ISA ram base + 0x00500000
VME 0xFEE00000 -> ISA ram base + 0x00600000
VME 0xFEF00000 -> ISA ram base + 0x00700000

[Atarian Computing]

Minor update which probably wont effect many.

Code: Select all

20251214:
  rom:      support EmuTOS Shutdown feature (when ckbd is present)
  rom:      removed nova driver specific pmmu mapping
  rvnova:   add nova driver specific pmmu mapping
  isa_bios: support isa-interrupt callbacks

As part of moving the Nova driver specific VME->ISA mappings from bootrom to rvnova.prg I took a stab at guessing what the Mach64 driver wants.

If someone has a Mach64 card then it could be worth giving it a go in the odd chance I actually guessed correctly..
I'd love to hear if it works or not since I don't have one of those to test with myself.


So I don't actually know for sure where the Mach64 driver is setting up vram in ISA space nor where that is in VME space, so this is mostly some kind of best-guess based on how the VME adapter schematic looks, and only very few minutes with the driver disassembly.

Based on that, as well as what the Mach32 driver is doing, I'm working with the theory that the driver is treating FEC00000 as start of vram in VME space and (ISA_BASE + 0x00400000) as the equivalent in ISA space.
Which could be a completely wrong guess so if someone actually knows then feel free to share :)

Code: Select all

VME 0xFE900000 -> ISA i/o base
VME 0xFEC00000 -> ISA ram base + 0x00400000
VME 0xFED00000 -> ISA ram base + 0x00500000
VME 0xFEE00000 -> ISA ram base + 0x00600000
VME 0xFEF00000 -> ISA ram base + 0x00700000

Cool. I'll be able to test that next Friday/Saturday

[agranlund]

What about use the 8bit ISA USB Controller, Annadue ISA-zu-USB card ...?

I think those would work just fine, but someone would have to write a driver for them.
There is also the XT-IDE and XT-CF-Lite as other alternatives.

Perhaps better yet are old generic 16bit Multi-IO cards?
Those provide IDE + Floppy and sometimes also Serial + Parallel all on the same card.
They would be faster, possibly much faster, than the newly made 8bit XT stuff. Perhaps even cheaper since they're hardly collectible.


But then again, the convenience factor of using usb thumbsticks with those CH375 based ISA cards is quite high.
Are the chinese ones clones of Lo-tech's card? Or the opposite way around? Or just same idea at the same time maybe :)
https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter

[redpixel]

If someone has a Mach64 card then it could be worth giving it a go in the odd chance I actually guessed correctly..
I'd love to hear if it works or not since I don't have one of those to test with myself.

I tested on my set-up, unfortunately it didn't appear to work. I didn't have a serial port because I had to steal the IDE-CF adapter from the Falcon, but it feels like something is wrong already at the VGA bios stage. It takes an awfully long time to "complete" (something like 30 s I think before the monitor gets a sync signal) and the part about 8-bit vgamem also feels weird I guess. This might of course be due to my card being non-functional, but it sounded to me like @Atarian Computing 's card was saying the same on the serial port.

I can't see anything with the Mach64 plugged in, so I set the BIOS up to use the MACH64 driver using my Mach32 first, then rebooted with the Mach64 plugged in. Screen sort of flashed a bit a few times (I guess when executing NOVA?), but stayed black.

[agranlund]

I tested on my set-up, unfortunately it didn't appear to work.

Worth a shot, thank for giving it a go!
Sound like the Mach64 bios isn't too happy with the emulated environment during bios stage.
That very long execution time I think is also hinting at something not being entierly correct.

Screen sort of flashed a bit a few times (I guess when executing NOVA?), but stayed black.

I'm guessing the same.
And probably that the memory map I guesstimated for that driver wasn't correct.

[agranlund]

Humm... it surely wont help that apparently I've only been tagging up 4MB of ISA memory space, starting at ISA:0

Code: Select all

    mmu_Map(0x80000000, 0x80000000, 0x00400000, PMMU_READWRITE | PMMU_CM_PRECISE);         // ISA-RAM (8bit)
    mmu_Map(0x82000000, 0x82000000, 0x00400000, PMMU_READWRITE | PMMU_CM_PRECISE);         // ISA-RAM (16bit)

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.