non-system startup code time/clock problem

[Toni Wilen]

Originally Posted by dissident

Good to know. If I understand it correctly the clock chip detection of the clock resource is fooled by random values.

Problem is that they are not random values. Most of the time.

Usually reading floating data bus returns whatever data CPU accessed previously but it is not guaranteed. I am not sure how it exactly works because it is not really defined and can depend on mainboard revision, used chip types etc..

For example if I dump first 200 or so bytes from 0xDC0000 (without clock), I get 100% repeatable results (seems to return last CPU's prefetched instruction word) except 1-2 bits that randomly change in random addresses.

Would that error also happen with my code?

It is possible.

[dissident]

Originally Posted by Toni Wilen

Problem is that they are not random values. Most of the time.

Usually reading floating data bus returns whatever data CPU accessed previously but it is not guaranteed. I am not sure how it exactly works because it is not really defined and can depend on mainboard revision, used chip types etc..

For example if I dump first 200 or so bytes from 0xDC0000 (without clock), I get 100% repeatable results (seems to return last CPU's prefetched instruction word) except 1-2 bits that randomly change in random addresses.

Thanks for your information Toni

[alpine9000]

Bumping this thread.

After some time has passed does anyone have any recommendations as to which is the best of the solutions discussed ?

[meynaf]

The best solution is to not kill the OS at all

[Thorham]

Originally Posted by meynaf

The best solution is to not kill the OS at all

Indeed

[alpine9000]

Originally Posted by meynaf

The best solution is to not kill the OS at all

That's no fun. The best thing about the Amiga is you are free to do whatever you like, including "pausing" the OS.

Anyway I ended up using one of the TOD solutions as it seemed to be the most compatible across various hardware/software configurations.

[meynaf]

Originally Posted by alpine9000

That's no fun. The best thing about the Amiga is you are free to do whatever you like, including "pausing" the OS.

You can bang on the hardware and still leave the OS alive. You just have to be polite and ask before using

[alpine9000]

Originally Posted by meynaf

You can bang on the hardware and still leave the OS alive. You just have to be polite and ask before using

I prefer to tell rather than ask

[Thorham]

Originally Posted by alpine9000

That's no fun.

Depends on the application. For demos and games it's not a big deal, but for other programs it's definitely a big no-no.

[alpine9000]

Originally Posted by Thorham

Depends on the application. For demos and games it's not a big deal, but for other programs it's definitely a big no-no.

Sure - in my case I took my track loaded game that was designed to run on my unexpanded A500, wrapped the code with someone else's "startup" code and it pretty much worked.

I didn't initially plan on doing a workbench version. Because it was so simple to build both versions I decided to keep the OS "compatible" version in the mix.

Trackloaded ADF is still my preferred medium. Works on all Amigas, including people running various UAEs that only have access to the AROS roms.

[Thorham]

Originally Posted by alpine9000

Trackloaded ADF is still my preferred medium. Works on all Amigas, including people running various UAEs that only have access to the AROS roms.

Doesn't work on Amiga's without a floppy drive, unless the track loader uses the OS

[alpine9000]

Originally Posted by Thorham

Doesn't work on Amiga's without a floppy drive, unless the track loader uses the OS

touché

I guess that group of people will need to run the workbench version.

[phx]

Originally Posted by meynaf

You can bang on the hardware and still leave the OS alive.

Not really. This is the absolute worst way to do it and will cause the most problems. A sign of bad software, IMHO.

Either you use the OS or take over the hardware completely. There is nothing in between.

[meynaf]

Originally Posted by phx

Not really. This is the absolute worst way to do it and will cause the most problems. A sign of bad software, IMHO.

Either you use the OS or take over the hardware completely. There is nothing in between.

Nope.
The OS has primitives to take over everything you need : screen, sound, blitter, cia timers, whatever.

There IS sometimes the need to touch the hardware under OS, f.e. try to play Protracker modules with audio.device alone - simply impossible.

[Toni Wilen]

It is never that black and white.

It depends what you want to do, if you want to do anything useful with basic A500, you really want to take over the system but if you target something higher, it is usually possible to keep system mostly working.

Trouble can still come when user has odd expansion(s) that take random amount of CPU (interrupt) time just when it shouldn't..

[phx]

Originally Posted by meynaf

The OS has primitives to take over everything you need : screen, sound, blitter, cia timers, whatever.

There IS sometimes the need to touch the hardware under OS, f.e. try to play Protracker modules with audio.device alone - simply impossible.

Ok, you're right. Seems I misunderstood you.

The same would be to call OwnBlitter() and program the Blitter registers. But this is still a legal, OS-conforming program for me. I thought about writing hardware registers while the OS is still alive and not aware of it, like in a bad Seka assembler source of 1988.

[alpine9000]

Originally Posted by meynaf

Nope.
The OS has primitives to take over everything you need : screen, sound, blitter, cia timers, whatever.

There IS sometimes the need to touch the hardware under OS, f.e. try to play Protracker modules with audio.device alone - simply impossible.

The other need to touch the hardware directly is because it's fun, interesting and different from the sort of boring programming that most programmers do for a living.

Calling OS APIs is sleep inducing in it's boringness :-)

The minimum calls required before I am in full control the better.

[meynaf]

Originally Posted by phx

I thought about writing hardware registers while the OS is still alive and not aware of it, like in a bad Seka assembler source of 1988.

That's indeed more than a little bad

Originally Posted by alpine9000

The other need to touch the hardware directly is because it's fun, interesting and different from the sort of boring programming that most programmers do for a living.

Yea but it ain't funny to debug.
File i/o is also quite painful.
So ok it's fun for learning things and all, but i wouldn't do it for any serious project.

Originally Posted by alpine9000

Calling OS APIs is sleep inducing in it's boringness :-)

Then design your own APIs. This is (more or less) what i did for my programs.

Originally Posted by alpine9000

The minimum calls required before I am in full control the better.

Perhaps you'd be better off by just writing $7fff to $dff096+$dff09a and never return

[alpine9000]

Originally Posted by meynaf

Yea but it ain't funny to debug.
File i/o is also quite painful.
So ok it's fun for learning things and all, but i wouldn't do it for any serious project.

The UAE debugger makes things a lot easier (and fun) to debug compared to a real Amiga. It would be less fun without that.

Is anyone doing any serious projects still on the Amiga ?

[meynaf]

Originally Posted by alpine9000

Is anyone doing any serious projects still on the Amiga ?

If by "serious" you understand "business" then no (hopefully ?).

Else, yes, maybe.
I mean, while demos and some games can be satisfied with os killing stuff, utilities and large projects (like a big game over 100MB in size) need to run under os.
Are there such projects now ? Well, there are a few game projects here and there. My personal current intent is to write a multi-format audio player. If i get some nice incentive i may eventually be porting another Atari ST game as well.