| OCS/ECS/AGA Flaws In the Coprocessors Themselves | page 1 2 3 4 5 6 7 8 9
|
|---|
|
|---|
Marcel Verdaasdonk Netherlands
| | Posts 3991 11 Apr 2011 18:02
| gunnar what is the largest chunk of data natami's blitter can move in a single action/command and what is the largest chunk in a single cycle?
| |
Børge Nøst Norway
| | Posts 53 27 Apr 2011 13:03
| Gunnar von Boehn wrote:
| Regarding the CIA Timing. Some old titles use this for programmed delays. For compatibility we should keep it this way.
|
It is officially documented that accessing the CIAs syncs you down to 0.7MHz. I have used it myself for delay loops (like fixing timings for my slow B2000 keyboard).Gunnar von Boehn wrote:
| Of course for Workbench its not needed to keep the CIAs slow. But Workbench will of course also run fine with slow CIAs. Maybe a simple upgrade way it to "map" the CIAS twice. In the old place in the original timing, and again in a new place with zero latency. This would allow Workbench and new applications to use get away of the delay. No big win but would not hurt...
|
This sounds like a Plan to me.
| |
Jakob Eriksson Sweden
| | (Moderator) Posts 1097 27 Apr 2011 14:18
| And then timer.device could be made to use the newer, fast CIAs?
| |
Thomas Richter Germany
| | (MX-Board Owner) Posts 1425 27 Apr 2011 15:27
| Jakob Eriksson wrote:
| And then timer.device could be made to use the newer, fast CIAs?
|
The timer device doesn't depend on the slow access speed of the CIA registers. Only on their clock frequency.There is one "glitch", though - at least if I remember correctly. Namely, the timer device doesn't use CIAs at all if the timer constant is too small. In that case, it busy-waits (IIRC) just by looping. Of course, the time constant for such loops is just outright wrong with the Natami. Greetings, Thomas
| |
Marcel Verdaasdonk Netherlands
| | Posts 3991 27 Apr 2011 17:04
| Thomas can you place a reference or a test case of it in this thread?
| |
Thomas Richter Germany
| | (MX-Board Owner) Posts 1425 28 Apr 2011 19:40
| Marcel Verdaasdonk wrote:
| Thomas can you place a reference or a test case of it in this thread?
|
Sorry, that's the trackdisk.device which does the busywait for timing if the time constant is too small, i.e. it does not call the timer device then. It is unclear what the motivation for this was. Likely because the old v33 timer.device was unreliable for too small delays, and nobody reviewed the code back then when CBM introduced the 040, so it just stayed this way. Apparently, the timing constants are computed for the 68000, not the 040. Funny. And it doesn't use CIA register access for delaying.Sorry, you need a disassembler to see what I mean, I cannot provide further evidence. So long, Thomas
| |
|