ST536 STE EDITION

[exxos]

Wow GPT4 fixed it...

1.PNG (12.45 KiB) Viewed 442 times

So TTram found..

IMG_3377.JPG (40.61 KiB) Viewed 442 times

No TTram found.

IMG_3378.JPG (50.05 KiB) Viewed 442 times

Now I can use that logic for my fast rom stuff soon

44.PNG (22.96 KiB) Viewed 438 times

[Cyprian]

Wow GTP can be useful though.
Did you paste it all the code or just part of it?

[exxos]

Wow GTP can be useful though.
Did you paste it all the code or just part of it?

By all the code you mean the whole operating system ? There is a limit on what you can paste and the more complicated problem is that more likely you will not find issue I think..

I just pasted in the TTram test routines, which is about 1-2 pages of code.

Grok wrote my ROMCOPY program. But on other things it makes mistakes and refuses to see them. If I then copied the same question to GPT, it generally finds the problem. But GPT seems to really struggle with writing 68k code...

For example,Grok was trashing A0, it was clear even to me it was wrong, but grok did whole analysis of NSAID in bold letters there is no mistake! The same question in GPT suggest there was a mistake and I should use another registers such as A3. I asked to fix the code and it did and it worked afterwards.

Other times neither AI can solve the problems or write working code. I think the longer the conversation the more confused the AI's become. So it seems best to start a new conversation for each problem and not let the conversation get to long. It makes sense as well because browsers slowdown longer the conversation gets. I would have thought after like 20 years this problem could have been solved by now

[exxos]

Assembly code is hard work ! Cant call a subroutine within the bus error handler.. super sulky where you put code and data...

My EPROM eraser has been on continuously for the past two days...

IMG_3379.JPG (102.55 KiB) Viewed 385 times

[stephen_usher]

Assembly code is hard work ! Cant call a subroutine within the bus error handler.. super sulky where you put code and data...

You sort of can if instead of jsr you use bsr and place the return address in a register (and your subroutine knows about this calling system).

Also remember that you may be using a different stack, the supervisor one.

In the last week I've been doing a lot of m68k assembler in regions where I don't have a stack (or any other potentially working memory).

[exxos]

I don't get it

Basically..

Code: Select all

DATA
error_flag:  dc.b 0
TEXT

Then a bit later.

Code: Select all

clr.b   error_flag 		/* clear error flag */

Then a lot later in the code.

Code: Select all

    tst.b   error_flag

It crashes like error_flag is not defined ?!

[exxos]

I think the some bizarre reason the error flag is being allocated into ROM.. As I can read from it, but not write to it.

So if I do

Code: Select all

error_flag: equ $00010000  /* safe ST-RAM location */

It then works.

Maybe a bit naughty doing that, But ST-RAM hasn't even been tested at that point.. which could be part of the problem

The flag will get trashed when ST-RAM test happens, but it doesn't get used again after that anyway.

[exxos]

Can't test fully in Hatari... but it gets the messages kicked out.. so it *should* do the ROM copy on the STE536.. need to burn the ROM and find out next...

1.PNG (17 KiB) Viewed 348 times

2.PNG (20.16 KiB) Viewed 348 times

[exxos]

SUCCESS!

Forced no TTram in firmware.. So this is correct..

IMG_3380.JPG (61.28 KiB) Viewed 336 times

Enabled TTram in firmware and this is correct..

IMG_3382.JPG (50.82 KiB) Viewed 336 times

.. and proof ROM speed is almost 800% now!

IMG_3383.JPG (109.67 KiB) Viewed 336 times

I need to do a ton of code tidying next It can be next weeks problem !

Oddly the colour changes don't work in Hatari at all


Thanks for flying exxos assembly experimental airways.

exxos over and out.

[Cyprian]

congrats @exxos !!!