Raven. A homemade Atari-like computer

[agranlund]

It's hard to explain in words...
Scenario 1: CF without BS and everything updated (ROM, software, etc.) everything works as usual.
Scenario 2: SD formatted with TOS, with BS and everything updated but not the software, nothing works, it opens directories with altered names, etc. I tried renaming AUTO to AUTO.OLD but everything stays the same.
I already know that the next step is to start from scratch. Format and partition the SD and put everything back as it was... If only there was something that could read the TOS partitions from a PC, because I would like to write the updated software without reformatting everything.

Thanks, I still think there's missing some details that are probably obvious to you but I can't really know.

I tried renaming AUTO to AUTO.OLD but everything stays the same.

I'm not sure I can know what 'everything' means here?
a) you renamed it to AUTO.OLD but rename is not working so the folder is kept being called AUTO ?
b) it was renamed to AUTO.OLD, but somehow TOS is running the programs from the renamed auto folder at startup.
c) it was renamed to AUTO.OLD, nothing runs at startup and you end up with black and white desktop you'd get with a super-clean boot etc.
- If even in this (c) scenario, when _nothing_ ran from an auto folder. Things are still broken related to cf-card operations?
If so, updated software isn't going to help at all I don't think, and most likely something on the cf has gone corrupt (fat table perhaps?)
Alternatively, maybe related to adapters(s) etc, in case that setup is different from when you were using the other card.
If you skip the byteswap adapter and use this same CF card without, does it work then (i suspect not) ?
Is even running programs from the rom-disk is broken here?


And when it runs your programs from the auto folder. Is <anything> out of the ordinary happening or that part is working as it should?
ie; you see the splash screen, your usual boot text scrolling, nova initialises your screen mode properly etc?
(since you never mentioned anything about this I am assuming this is working as you expect?)

Tos error 35 can mean corrupt file.
It could also just mean that the file isn't actually corrupt on disk, but something goes wrong and the data loaded in memory becomes corrupt for whatever reason, or it can mean other things too probably.
My hunch is on something on the card is corrupt, requiring you to reformat it, but the best would be if it's something else.

This is partly why I keep asking about what happens when you run program from the rom-disk (not cf-card)
To see if it's only related to stuff on the CF or if tos error 35 happen even if you run something like ymodem.tos from ROM

If only there was something that could read the TOS partitions from a PC, because I would like to write the updated software without reformatting everything.

Yeah that would be nice.
Probably it is possible to image the card, use image with Hatari, and then re-write the image back on the card, but I never tried.

But still. If the rom-disk works (?) then you should be able to run ymodem.tos from it and send files over to the cf-card in Raven.

Assuming it's going to be able to actually write those files to the cf card but from the new info I'm suspecting that's not going to work either -- but it's still something I would have tried before formatting and starting over.

[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

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 (689.31 KiB) Viewed 719 times

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 (72.06 KiB) Viewed 719 times

[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.