Posted By
MasK
on 2007-02-06
18:36:33
|  Re: Plus/4 Expansion port...
MikeD,TLC!! I have an idea about the improved freezer cartidge...I will try it on next week...but i'm sure it must work perfectly.
TLC's extended freezer idea (pulling data bus low,to reach a "BRK") a very interesting trick,but have a leak...how we can know,CPU fetches an instruction right now?
The short answer is more-more simpler,than we think,for first look..
We don't need a big ,complicated hardware,counting cycles,checking address and data bus..etc.
There is some DMA technique in our little computer.
TED "stops" the CPU when it need bus access in both half of CLK signal,asserting BA and then AEC low.
Why the TED waiting some (always 4!) cycles before totally refusing bus access from CPU?
Because,all members of the 65xx CPU family,can only "insert wait states" when already completely finished an instruction,and next fetch cycle is coming...
Yes,this is the point!! It's very simple!!
We must wait (a common edge clocked flip-flop will do for that) until TED starting,and finishing next DMA cycle.
At that moment,when BA released,and CPU can "work again",it is sure,a fetch cycle is coming shortly,as CLK goes high,we can pull down the data bus!!
CPU fetches a BRK immediately,jumping to an interrupt...going to read FFFE etc..from this point we can use simply "spedy like" mechanic,to catch execution in undecoded address space and do our little tricks from here:D
Some good coders are maybe help us,with an improved freezer style monitor...
Tedmon is good for common applications,but based on kernal,using many zero page variables....etc,etc....useless for a real freezer.
There is another,"software side" problems too...
For a correct,ram editing,"monitor enabled" freezer cartridge,we must use external ram,to avoid damage a single byte in the freezed code.
We need the zero page,because indexed instructions and stack,so freezer code must copy it's contents (at least partially) to external ram,very-very first..
Screen data should copy too...
But!! There is no way,to do that,what C64 freezer does!
An externally connected SRAM never "covers" totally the internal ram!
When data is written by the CPU,not the "rom decoded" external SRAM is working,but the internal dram's content changing.
We can't avoid that...or maybe on a "barbaric way",brute force pulling CAS high,like c16 external ram cartridge does that.
Luckily,the undecoded address space is exist..with a lot of work,we can catch our goals while using correct solutions.
There is only one right way:map the external ram there(small,swapped pieces) and copy data out,trough that small window.
We should do all that backwards,when freezer is exiting,and we are returning to leaved code.
|
