Raven. A homemade Atari-like computer

[Cyprian]

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

my fault, I mixed TOS/NEWDESK.INF description with EmuTOS.

Anyway:
https://github.com/emutos/emutos/blob/m ... app.c#L113

Code: Select all

                            /* 'E' byte 5 */
#define INF_E5_NOSORT   0x80    /* 1 => do not sort folder contents (overrides INF_E1_SORTMASK) */
    /* the next 2 apply when launching an application that is not an 'installed application' */
#define INF_E5_APPDIR   0x40    /* 1 => set current dir to app's dir (else to top window dir) */
#define INF_E5_ISFULL   0x20    /* 1 => pass full path in args (else filename only) */
#define INF_E5_NOSIZE   0x10    /* 1 => disable 'size to fit' for windows */
#define INF_E5_NOCACHE  0x08    /* 1 => disable cache */

[Atarian Computing]

my fault, I mixed TOS/NEWDESK.INF description with EmuTOS.

Anyway:
https://github.com/emutos/emutos/blob/m ... app.c#L113

Code: Select all

                            /* 'E' byte 5 */
#define INF_E5_NOSORT   0x80    /* 1 => do not sort folder contents (overrides INF_E1_SORTMASK) */
    /* the next 2 apply when launching an application that is not an 'installed application' */
#define INF_E5_APPDIR   0x40    /* 1 => set current dir to app's dir (else to top window dir) */
#define INF_E5_ISFULL   0x20    /* 1 => pass full path in args (else filename only) */
#define INF_E5_NOSIZE   0x10    /* 1 => disable 'size to fit' for windows */
#define INF_E5_NOCACHE  0x08    /* 1 => disable cache */

Ok, so I had 60 which was:

- **Sort**: ON (NOSORT bit is 0)
- **Launch directory**: Application's directory ✓
- **Launch parameters**: Full pathname ✓
- **Size to fit**: ON (NOSIZE bit is 0)
- **Cache**: ON (NOCACHE bit is 0)

setting it to 68 allowed me to boot to desktop.

[Cyprian]

great

[agranlund]

setting it to 68 allowed me to boot to desktop.

Nice find.
Your investigation sounded too much like it wasn't the usual some program misbehaving with copyback, so I had to test here too and was able to reproduce it easily.

Here's what I tried:
Removed emudesk.inf, enable copyback, and it booted up fine (cache fully enabled during the entire boot process and verified again by looking at the CACR register after having reached the desktop). This was with all (*) my usual known copyback compatible programs, nova, nvdi, all that.
(*) except I found out apparently my own rvsnd.prg isn't copyback compatible so that went on the todo list..

Then, saved desktop to generate emudesk.inf, cache option set to ON (60).
Now instant-death regardless of programs in auto folder. It appears to explode when EmuDesk obeys the inf setting and goes about to enable the already enabled cache.

So you're absolutely right, something must have happened in a recent update and I'll take a look.

Setting it to 68 makes EmuDesk turn off the cache as soon as it reaches the desktop and that it survives, but now you're in a worse situation performance wise compared to sticking with writethrough cache
(also verified by breaking into the debug monitor and looking at the CACR register after reaching desktop)

[agranlund]

Code: Select all

20260107:
rom: fixed crash when running with copyback cache enabled.

https://github.com/agranlund/raven/rele ... .A1.latest
@Atarian Computing

[Atarian Computing]

@agranlund, here is my washed out color issue. Would you know anything that would affect this?

I took screenshots of what the colors should be and a camera shot of the exact same spot:

Notice the folder gradient is missing completely:

FolderScreen.png (125.08 KiB) Viewed 192 times

FoldersCamera.png (2.32 MiB) Viewed 192 times

It's as if there's no colour "resolution". Similar shades appear the same.

CPXScreen.png (84.2 KiB) Viewed 192 times

CPXCamera.png (4.9 MiB) Viewed 192 times

Finally, here's a colour corrected camera shot of Nova Color. I've averaged the colors due to the pixels. Colors on the right are what they are supposed to be. The highlighted light grey is practically white.

ColorComparison.png (2.98 MiB) Viewed 192 times

What I've done to somewhat overcome this is edit the Nova Color palette for the greys to actually show difference. So 217 217 217 becomes 185 185 185 etc. That only fixes greys and it's too much work for the other shades. Also, a negative effect is that your screenshots are way too dark and colors wonky.

I believe everyone has this issue from what I've looked at from screenshots from users.

Edit: Important clarification; this happens on my other monitors as well.

[Atarian Computing]

Code: Select all

20260107:
rom: fixed crash when running with copyback cache enabled.

https://github.com/agranlund/raven/rele ... .A1.latest
@Atarian Computing

Thanks!! Can confirm, CB works as it should!

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.

Updated Iksi without issue. This still needs the Raven-specific build for MagiC? As in the IDE-without-interrupts wasn't the only unique thing to Raven? Do IDE interrupts affect performance in any way, btw?

[agranlund]

Thanks!! Can confirm, CB works as it should!

Nice!

Updated Iksi without issue. This still needs the Raven-specific build for MagiC? As in the IDE-without-interrupts wasn't the only unique thing to Raven? Do IDE interrupts affect performance in any way, btw?

Yep, there are other unique things in the Raven build so it's still needed.
The IDE interrupts doesn't make any practical difference as it stands. Mostly makes me feel good that it works the same as on real Ataris, and to have one less thing to patch should someone port Atari TOS.

EmuTOS and HDDriver does not use them at all, and since I already changed MagiC's bootsector loader to work without then it will stay that way as to still work with un-updated Iksi firmwares.
I don't know if AHDI or other drivers requires them but if they do then at least that would be one benefit of this firmware update

[agranlund]

@agranlund, here is my washed out color issue. Would you know anything that would affect this?

Nope, not sure. What card and driver is this?

I guess I had somewhat of the opposite issue with the image looking good (as far as I can tell) on the monitor but very washed out in screenshots taken by the framegrabber, to a degree very similar as you posted.
Randomly changing OBS settings somehow made it look the same as on the monitor but I don't know what setting it was

[Atarian Computing]

@agranlund, here is my washed out color issue. Would you know anything that would affect this?

Nope, not sure. What card and driver is this?

I guess I had somewhat of the opposite issue with the image looking good (as far as I can tell) on the monitor but very washed out in screenshots taken by the framegrabber, to a degree very similar as you posted.
Randomly changing OBS settings somehow made it look the same as on the monitor but I don't know what setting it was

Interesting. For me it happened with both the ET4000AX and GD5434. I could've sworn that one time with the Mach64 the colors were spot on.

I decided to check further and found a cheap-ass VGA->HDMI converter, and sure enough, the colours seemed fine, albeit a tiny bit on the bright side. This tells me that the VGA output is fine from the card, and it's just that my monitors are not handling it properly or something.

This particular VGA->HDMI can't handle the BIOS resolutions and has some ghosting, so I might try to find a better one. What are you using and would you recommend it?