exxos's Atari, Amiga & retro forum

Made a bit of progress. A lot of the window drawing routines and related code have been totally rewritten. Ended up with some right strange bugs all over the place.

But decided that now in a multitasking environment, there is no need to actually hide the main gem bench window. So now is kept open during the tests.


While the current selected test flashes black a few times, if you press a key at that point, it will abort whatever cycle it is running. So you can break out of "All tests" or "loop all" now. I know it was a minor annoyance to a few people including myself not being able to stop the thing from running.

I need to fix some window locations in some of the tests next. All the confusion of writing GB6 originally, I did different ways of basically doing the same thing across the tests. Though some are slightly broken and others aren't :roll: But they *should* be relatively simple things to fix.

I want to adding something like NEMBENCH and/or NEMSPEED as well. Basically a MB/sec series of tests which can open in its own window. So if anyone can help out with some assembly routines to do such tests then please let me know..

I'm going to add in a cookie viewer as well. It is just immensely irritating to keep loading SYSINFO just to view the cookies installed all the time. I may add some "quick scan" routines in there just to test out what TTram is installed as well.

You know what @exxos ?

I've got to hand it to you, when you decide to dip your toe into doing a bit of coding, you don't really do half measures, do you? :lol:

So what, you are dealing with the quirks/limitations/workarounds of a BASIC dialect, whilst it is interfacing to assembly and dealing with that too (again in a non standard or at least non documented way, IIRC from what bits you sent my way), then on top of that, learning the VDI/AES way of things too (and multi-tasking too).

mrbombermillzy wrote: 25 Dec 2022 14:23 You know what @exxos ?I've got to hand it to you, when you decide to dip your toe into doing a bit of coding, you don't really do half measures, do you? :lol:

:lol: Yeah jump in at the deep end and just see how things go. Work out one problem at a time.. Total chaos. :)

mrbombermillzy wrote: 25 Dec 2022 14:23 So what, you are dealing with the quirks/limitations/workarounds of a BASIC dialect, whilst it is interfacing to assembly and dealing with that too (again in a non standard or at least non documented way, IIRC from what bits you sent my way), then on top of that, learning the VDI/AES way of things too (and multi-tasking too).

Yeah. I think I have re-wrote like 80% of the GB6 code now. All to just move a window! :lol: :roll: But it needed a overhaul anyway. GB6 was my first app. So there's a lot of bodged code and redundant code all over the place. Oddly it's 30K smaller now , that's even after adding in stuff :lol:

I still need help with the asm code :( I need to figure out how to verify the numbers in some of the tests its doing and pass the extra pass/fail variable back to GB7 to flag up if verification passed or not.

exxos wrote: 25 Dec 2022 18:58
Yeah. I think I have re-wrote like 80% of the GB6 code now. All to just move a window! :lol: :roll: But it needed a overhaul anyway. GB6 was my first app. So there's a lot of bodged code and redundant code all over the place. Oddly it's 30K smaller now , that's even after adding in stuff :lol:

I still need help with the asm code :( I need to figure out how to verify the numbers in some of the tests its doing and pass the extra pass/fail variable back to GB7 to flag up if verification passed or not.

If it's well documented then maybe that's ok, but otherwise...swimming against a strong current is the vision that comes to mind for me. And that equates to much more time spent trying to detangle/key in to what is actually happening (or what the original coder envisioned) in the code; that's if I don't have to figure out a high level languages nuances or features/bugs.

I mean, there are certain folks on this forum who can probably build a 1/10th scale fully working nuclear submarine in their back pond within a week, but ATM I'm not having that level of time availability/focus unfortunately. [Insert an 'I am not worthy' smilie here]

Have you discussed the latest changes with Doug at all?

'Verification' in the above quoted case, sounds very much like very tight timing differences.

For me, at least, I find since Ive migrated from TT to ST (well MST) that the cycle timing is *much* easier to predict on the 68000 than the 030. I have no experience at all on any of the other CPUs that are in that code you originally sent me, either...and if you've seen any of my non image related (i.e. UI) code, I use the VT52 emulation :lol: because I still haven't had time to crack the AES yet and it is 'good enough' for my own purposes.

On the 030 (well, using non recurrent data anyway, if not instructions) there's always timing jitter, as you never can quite tell when the data/instructions will get a boost/penalty . It didn't really matter in what I was needing (i.e. I could compensate or ignore), so I haven't really looked into this side of things any further.

With all the above in mind, if you are really struggling and really need this done and cant find anyone more suitable, I don't mind trying to help out, as long as time isn't a critical factor for you :)

If you need proper timing you can’t do it from within the CPU itself. You’ll need an external timer to trigger an interrupt or some other hardware event which is independent of the CPU. I guess that you could use one of the MFP timers.

I don't think I was clear enough what I was referring to..

I'm talking about integer division for example does not verify the calculation afterwards. Generally the program would crash if the CPU was screwing up badly. But a couple of bad bits here and there would not cause that to happen.
The loop count is set by GB6/7 which is 2000 loops, of it seems 1024 loops. Inner and outer loops I presume.

So I assume it does 1024 loops, 2000 times.

The idea being it would do those 1024 loops, and compare the result to whatever the result is supposed to be, and give it a "pass or fail bit", then onto the next loop until it has done 2000 loops in total. This bit will be transferred back to GB7 which is the code @dml Helped me fix up last week.

So basically I think it would be something like this, in basic analogy..
The return code to pass data back to GB7 is this.
I forgot where I got up to with it all but I do know the example routine we did does work. I should be able to figure that out anyway. But the integer division loop needs to set a register bit somewhere to default as zero, then set to 1 if a loop failed. I can then read that value in GB7 and flag up that the test failed somehow.

Some oddities with the first test in XaAES..

I think part of the problem was that text was missing because I had a text box on top of a text box. So I did away with the red text that seems to have partly solved that problem. Note the location of the main GB7 window is different and it effects the test window.. crazy.

However I don't understand where the actual word TEXT is coming from because it does not appear to be in the RSC file even :shrug:

Works fine in vanilla TOS as well.


EDIT:

I removed the inner box and the 2 blank lines and the TEXT words still show up :shrug:


EDIT2:

Removed the entire middle section and it still shows up... :WTF:

I have sidestepped the above issues were now as I have no idea why it is doing that. My be a bug in outside of GB7 :shrug:

I have been fixing up other routines today. Ordinarily I would close the main window to display pop-up messages like the saved defaults question box. Technically this would not be needed in the multitasking environment.. As if the main window is "off to one side" though technically no reason to close it to display a pop-up box.. But there is really no way to make this simple.. Because GB7 would have to decide if to close the main window to display the pop-up box, or display the pop-up box over the main window which always looks messy to me and may get missed by the user.

There could be clauses that if the main window is 200px away from the centre of the screen then there is no need to close the window. Then just pop the question box in the centre. But I think it is just getting a lot of clauses in the code to do that. And I am confused enough already as it is :lol: :roll:

So for the time being the main window will be closed for question boxes which is how it is in GB6 anyway.

I've also had to write clauses in for redraw events. Because up to now I manually call my redraw functions in TOS. but the problem is when running a multitasking environment, the AES tends to send redraw messages itself. So in terms of what I am doing, I end up with the screen refreshing twice in the multitasking environment. So I have had to put clauses into not manually refresh the screen on the multitasking environments. Only refresh it on the TOS manually :stars:

Occasionally something triggers it to refresh twice anyway but it is difficult to track down exactly what point this happens. I have noticed while using the WM_ redraw events or whatever, it can actually end up in a loop of constantly refreshing the screen. So I have been dealing with those bunch of weird issues earlier and it seems basically okay now.

That's all the progress for the time being because I am away from my girlfriend for the next couple of days now having some time off :)

I’m not sure if a “benchmark” on a multi-tasking system which doesn’t have control over the scheduler is very valid as it would depend upon what other tasks are running as to how many time slices the benchmarking software will get. Also, if the other gals are doing I/O the benchmark will get suspended for unknown amounts of time.

stephen_usher wrote: 26 Dec 2022 21:58 I’m not sure if a “benchmark” on a multi-tasking system which doesn’t have control over the scheduler is very valid as it would depend upon what other tasks are running as to how many time slices the benchmarking software will get. Also, if the other gals are doing I/O the benchmark will get suspended for unknown amounts of time.

I have been saying that since day one (it's in the readme) that it should not be used on a multitasking environments. But people do it and want it to function properly. I am merely addressing the general "complaints" had over GB6 about such things. I only ever recommended medium resolution without a multitasking environment. Aside from tidying up all my old code I have also been fixing the AES issues so people can have it more user-friendly multitasking environments. If people want to run 20 programs at once maxing out the processor then complain the benchmark result are screwy, then not my problem.