Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > (Ab)use of dummy accesses
2020-03-09 17:04
chatGPZ

Registered: Dec 2001
Posts: 11386
(Ab)use of dummy accesses

For the next release of my "No more Secrets" doc i am preparing a chapter related to the dummy access which happen when the CPU performs an internal operation. Once again i am looking for some examples on how to (ab)use it :) I guess everyone knows "inc $d019" - but i am sure there is more than this. And not only with RMW instructions. So if you have anything in your mind - just drop it here!

here are some related notes which i pasted together. feel free to proofread and point out mistakes :)
 
... 55 posts hidden. Click here to view all posts....
 
2020-04-07 15:05
chatGPZ

Registered: Dec 2001
Posts: 11386
"They" didnt change it - its a sideeffect of how the signal propagation delays in the chip, and so it changed when they moved from one process to another.
2020-04-08 17:22
lft

Registered: Jul 2007
Posts: 369
It is possible to start a REU transfer by writing to address $ff00, which is useful when you want to transfer to or from memory in the $d000-$dfff range. But sometimes you don't want to trash the byte at $ff00, so you end up starting the transfer like this:
        lda $ff00
        sta $ff00
However, it turns out you can use any RMW instruction:
        inc $ff00
The dummy write causes the REU to immediately take over the bus, so the second write-request from the CPU doesn't reach the memory chips. The incremented value never gets written into RAM. Three cycles saved.
2020-04-08 17:45
chatGPZ

Registered: Dec 2001
Posts: 11386
woa, thats... unexpected (to me at least). nice!
2020-04-08 21:13
MagerValp

Registered: Dec 2001
Posts: 1078
That’s certainly unexpected. So what happens during the last cycle, bus conflict?
2020-04-08 23:00
lft

Registered: Jul 2007
Posts: 369
The 6502 has two inputs, /RDY (Ready) and /AEC (Address Enable Control). RDY tells the CPU to pause execution, but it is only obeyed during read cycles. AEC immediately disconnects the CPU from the buses (address, data, and the read/write signal).

The VIC chip has two outputs, BA (Bus Available) and AEC (Address Enable Control). During normal operation, VIC asserts AEC (which is connected to AEC on the CPU) on every other half-cycle in order to read e.g. font bits. It has to work immediately, i.e. asynchronously, because it needs to be fast enough for half-cycle operations.

When VIC needs to halt the CPU, it first pulls BA low for three cycles, to ensure that the CPU is on a read cycle. Then it asserts AEC in order to access memory on both half-cycles.

The expansion port has an output, BA, and an input, /DMA. BA comes from the VIC. But /DMA is connected to both /RDY and /AEC. That is, it tells the CPU to pause, but it also immediately disconnects the CPU from the buses.

The REU monitors BA so it can pause an ongoing transfer during badlines and sprite fetches. But otherwise, it pulls /DMA and just assumes that the bus is free. The engineers must have assumed (wrongly) that the CPU will always trigger a transfer on the last cycle of an instruction, so that the next cycle is guaranteed to be a read (to fetch the next instruction).

Instead, due to the double-write of our RMW instruction, part of the CPU will attempt to place an address and data value on the buses, and set the read/write line to write. But the CPU is disconnected from the buses because /DMA is held low, and therefore /AEC. The bits never reach the actual bus lines; they dissipate into a small amount of heat.
2020-04-09 00:07
Zyron

Registered: Jan 2002
Posts: 2381
:o
2020-04-09 07:25
MagerValp

Registered: Dec 2001
Posts: 1078
Neat!
2020-04-09 10:21
chatGPZ

Registered: Dec 2001
Posts: 11386
that calls for a test program that breaks emulation :)
2020-04-09 12:10
oziphantom

Registered: Oct 2014
Posts: 490
Quoting lft
The engineers must have assumed (wrongly) that the CPU will always trigger a transfer on the last cycle of an instruction, so that the next cycle is guaranteed to be a read (to fetch the next instruction).

Or explicitly put in the programming guide/datasheet.
'Thou shall not write to thing with anything else other than ABS.'
2020-04-09 14:23
Oswald

Registered: Apr 2002
Posts: 5094
I dont get it, if REU starts to use bus as soon as VIC signals on BA to processor to stop, then it will lead to a bus conflict ?
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
csabanw
Bitbreaker/Performers
Chesser/Blazon
Sychamis
Isildur/Samar
Holy Moses/Role
Steffan/BOOM!
AArt1256/MoonShine
Guests online: 108
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Fullscreen Graphicians
1 Joe  (9.7)
2 Sulevi  (9.6)
3 The Sarge  (9.6)
4 Veto  (9.6)
5 Facet  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.055 sec.