You will not be able to post if you are still using Microsoft email addresses such as Hotmail etc
See here for more information viewtopic.php?f=20&t=7296
See here for more information viewtopic.php?f=20&t=7296
Check if your IP is banned
viewtopic.php?t=7286
viewtopic.php?t=7286
ST536 STE EDITION
Re: ST536 STE EDITION
I hacked in "desktop preferences" just for a "hello world" type thing. Both my menus are detected when clicked on and it brings up the pref-box ! So that's something at least.
Re: ST536 STE EDITION
Got the blitter tick untick working, it also enables and disables the blitter correctly now
One "bug" I am trying to fix is when a external program alters the blitter state because TOS doesn't know about it, and the desktop menu setting becomes invalid. So looking into what I can do to update/verify what the menu tick does next..

One "bug" I am trying to fix is when a external program alters the blitter state because TOS doesn't know about it, and the desktop menu setting becomes invalid. So looking into what I can do to update/verify what the menu tick does next..
Re: ST536 STE EDITION
The next annoying thing is I cannot seem to figure out how the menu updates specifically 
I do this..
Now this does work, but it only seems to actually update the menu after the menu has been clicked on..
For example I am in a weird state where I can click anything in the menu and the blitter tick will update accordingly but only when the menu has been clicked on.
It doesn't seem the menu data is refreshed each time the actual options menu is redrawn. Even exiting the menu and going back in does not trigger a new menu update
I can see what happens after menu item is clicked on, and the tick will update then. But there isn't really anything to force a menu refresh from what I can see. But it must be there somewhere to update the ticks in the first place.
EDIT:
I don't think its possible to fix
Theres no menu events I can see to trigger anything, only when something is clicked on does it trigger a menu event 
EDIT2:
Or possibly just patch blitmode to change the menu but that seems like a bad idea as something could change the mode in a game or something and there be no menus to refresh..

I do this..
Code: Select all
if (ret & 0x1) { /* BLiTTER is enabled */
menu_addr[BITBLT].ob_state |= CHECKED; /* Check menu item */
} else {
menu_addr[BITBLT].ob_state &= ~CHECKED; /* Uncheck menu item */
}
For example I am in a weird state where I can click anything in the menu and the blitter tick will update accordingly but only when the menu has been clicked on.
It doesn't seem the menu data is refreshed each time the actual options menu is redrawn. Even exiting the menu and going back in does not trigger a new menu update

I can see what happens after menu item is clicked on, and the tick will update then. But there isn't really anything to force a menu refresh from what I can see. But it must be there somewhere to update the ticks in the first place.

EDIT:
I don't think its possible to fix


EDIT2:
Or possibly just patch blitmode to change the menu but that seems like a bad idea as something could change the mode in a game or something and there be no menus to refresh..
Re: ST536 STE EDITION
Anyone know of any programs which will list the cache state ?
I'm really confused how TOS is setting it. There just seems to be a global variable called "s_cache" for true / false. But i cant see anything which does anything with the value.
Theres a SET_CACHE function, but if I try and use it, it wont compile. So im not sure at this point if the cache on/off is working or not
Is also the possibility that Hatari doesn't even emulate the cache stuff ?, so might need to try on real hardware
I'm really confused how TOS is setting it. There just seems to be a global variable called "s_cache" for true / false. But i cant see anything which does anything with the value.
Theres a SET_CACHE function, but if I try and use it, it wont compile. So im not sure at this point if the cache on/off is working or not

Is also the possibility that Hatari doesn't even emulate the cache stuff ?, so might need to try on real hardware

Re: ST536 STE EDITION
I think I just figured out one big puzzle
Because this compiles
WITHOUT any brackets. So when I add another line in there, it refuses to compile.. But now I added in some brackets, it compiles... Stupid syntax crap!!
So I will have to burn a new ROM and see if the logic actually works or not now...
At this point not even sure the original cache on/off logic even did anything in TOS
Because this compiles
Code: Select all
if (s_cache)
menu_addr[CACHE].ob_state |= CHECKED;
else
menu_addr[CACHE].ob_state &= ~CHECKED;
So I will have to burn a new ROM and see if the logic actually works or not now...
At this point not even sure the original cache on/off logic even did anything in TOS

Re: ST536 STE EDITION
Yes. Always stick the if/else stuff in bracketed statementlists - otherwise, depending on the age of the compiler and how long and fuzzy the statement gets, it can either not compile, or worse - does compile to something you didn't want. Classic dangling-else syntax ambiguity with C languages.exxos wrote: Mon Jun 09, 2025 4:50 pm I think I just figured out one big puzzle
.....
But now I added in some brackets, it compiles... Stupid syntax crap!!
The brackets don't cost anything so just add them unless it is something really simple like 'if (flag) return;' but better just stick to the brackets and not worry about corner cases.
Re: ST536 STE EDITION
Yeah it seems a bit like someones "lazy coding" somehow.dml wrote: Mon Jun 09, 2025 5:31 pm The brackets don't cost anything so just add them unless it is something really simple like 'if (flag) return;' but better just stick to the brackets and not worry about corner cases.
Re: ST536 STE EDITION
I used SI.CPX and it looks like the cache stuff is working so far..
CACHE OFF
CACHE ON
The blitter on/off is reported the same in SI.CPX as well.
Just need to figure out that blank line in the menu now
Suppose I could make it a mystery option
Seems to have been a SUPERITEM , something to do with the cache
CACHE OFF
CACHE ON
The blitter on/off is reported the same in SI.CPX as well.
Just need to figure out that blank line in the menu now

Suppose I could make it a mystery option

Seems to have been a SUPERITEM , something to do with the cache

Code: Select all
menu_addr[SUPERITEM].ob_type = G_USERDEF;
chxcache.ub_code = (intptr_t)ch_xcache;
menu_addr[SUPERITEM].ob_spec = (intptr_t)&chxcache;
Re: ST536 STE EDITION
One possible thoughts, I don't know if @Badwolf or @dml have any thoughts about this..
I could actually have a menu to enable or disable STram cache...
Some stuff may work better or some stuff may not work at all..
It also just dawned on me that doesn't the blitter on off get saved in the desktop.inf ? That could possibly be broken now.. it would need the desktop.inf format updating somehow which probably isn't a good idea either..
I could actually have a menu to enable or disable STram cache...
Some stuff may work better or some stuff may not work at all..
It also just dawned on me that doesn't the blitter on off get saved in the desktop.inf ? That could possibly be broken now.. it would need the desktop.inf format updating somehow which probably isn't a good idea either..
Re: ST536 STE EDITION
There are bits / fields in the .inf for blitter etc. I don't know how many are free to grab but last time I looked it didn't seem fully utilised.
As for reading/interpreting/writing that info though in the .inf load/save code - that's probably a separate thing. :/
As for reading/interpreting/writing that info though in the .inf load/save code - that's probably a separate thing. :/