| |
soci
Registered: Sep 2003
Posts: 480 |
Reu test needed (real hardware)
Hello all!
As the R65C02 BBR/BBS test was such a great success, I try something else now ;)
Here's another small test:
http://singularcrew.hu/temp/reutest.prg
This is for testing the timing of REU DMA writes on a PAL C64.
I'm looking for someone who could take screen shots running this on real hardware equiped with a REU and a small description what hardware was used. Or better take a picture about that too ;)
It'd be nice if the picture could show the whole screen and a close-up to the left and right borders where it gets "interesting". Preferably in a way that individual colours of horizontal line segments can be identified. Yes there will be colour blending to some degree no matter what. S-video is preferred, but at least set up contrast and colours properly ;)
Thanks! |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
reminds me to clean up the various REU tests i made and push them to the VICE repo :) (please do the same with this one :))
will make some screenshots now... |
| |
Fierman
Registered: Feb 2002
Posts: 85 |
http://i.imgur.com/XgWW5IM.jpg
http://i.imgur.com/WHVIMY1.jpg
http://i.imgur.com/rRxrB6u.jpg
assy 250407 & 1750 reu on sony pvm (600 lines, svideo)
hope the photos are good enough. if not i can try again. |
| |
soci
Registered: Sep 2003
Posts: 480 |
Thanks everyone!
Some time ago I could hack that 1 cycle extra into x64sc for the first line of sprite 0 (mentioned long ago in a thread), but that just made it identical to the 1541U, which is not much of an improvement.
The pictures seem to indicate that the REU can reuse the first cycle of BA. Implementing this I can get an identical picture on x64sc:
Unfortunately this is not enough to get good results for Treu Love yet. Possibly I need to come up with another test... |
| |
CRT
Registered: Oct 2012
Posts: 87 |
A tad late but..
http://censordesign.com/pixcen/reu/ |
| |
soci
Registered: Sep 2003
Posts: 480 |
Thanks! Not late, it's good as cross check. So far all REUs behaved the same, that's good.
I've made another test to check the area previously hidden by the bitmap, as the end of bad lines were not visible so far.
http://singularcrew.hu/temp/reutest2.prg
I'd be nice to have a screen shot of this as well. Thanks! |
| |
CRT
Registered: Oct 2012
Posts: 87 |
Test2
http://censordesign.com/pixcen/reu2/ |
| |
soci
Registered: Sep 2003
Posts: 480 |
Thanks!
It's matching up with the model nicely:
Meanwhile I've found that there's an additional dummy cycle in case the DMA ends in a badline. This made the demo mentioned above work.
There are still small bugs on the right side every once in a while, but I think this is how it's on real hardware as well:
Can anyone confirm this? This was there in the original VICE "optimized" version as well when run on old x64sc.
I've committed a write improvement patch as r31436. With the limited testing I've done I couldn't find regressions yet.
Old VICE "optimized" code will likely fail, it's not a regression if it fails on real hardware as well.
There may be different versions of hardware as well, but so far all were behaving the same. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
cool!
so, drop the source into testrepo (or whatever) so i can integrate it properly :) (all existing tests still pass btw, good!) |
| |
soci
Registered: Sep 2003
Posts: 480 |
Too late, it went straight into trunk. For sure it'll need clean up now as I didn't use the VIC-II model tables for that sprite 0 extra cycle...
The answer for the right side sprite bug was buried in the demo thread already, it's ok.
Btw. I've made these changes for the other popular "emulator" as well in the experimental tree (r376). The result looks fine with my C64.
I think there's still a need for verifying the read side of the timing, as that could be off as well. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
oh i dont mean the reu fix itself, i mean the source for your test programs :=) its all automatic/scripted testing now (which needs some trivial patching to your test progs probably) |
| |
soci
Registered: Sep 2003
Posts: 480 |
Ok, it's in r31444 now. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
... and added to the testbench. cheers! |
| |
Grue
Registered: Dec 2001
Posts: 162 |
Quote: Too late, it went straight into trunk. For sure it'll need clean up now as I didn't use the VIC-II model tables for that sprite 0 extra cycle...
The answer for the right side sprite bug was buried in the demo thread already, it's ok.
Btw. I've made these changes for the other popular "emulator" as well in the experimental tree (r376). The result looks fine with my C64.
I think there's still a need for verifying the read side of the timing, as that could be off as well.
Can you provide binaries for the "other popular emulator"?
I've been itching to try your changes on 1541 ultimate :) |
| |
soci
Registered: Sep 2003
Posts: 480 |
I've PM-d a link.
In general I don't distribute pre-compiled binaries widely as then the support nightmare will break loose, and I have limited time to cope with it.
My testing is limited to a single piece of hardware (1541U-II) and some of my group mates burn in a version every once in a while. No causalities so far, but I've almost bricked mine twice due to my own mistakes in the code.
It might work elsewhere but might just as well brick it. It's not just an application update, so it comes with a greater risk.
For those feeling experienced (or adventurous) I can give out pre-compiled versions, no problem, but it's all your own risk and problem when something goes wrong. Those who can compile it from the repository are assumed to know what they're doing ;)
Btw. the stuff is about back-porting 1541 fixes to 2.6, some VIA timer updates, more accurate cartridge emulation and the addition of the IDEDOS cartridge.
And yes, that REU demo still has some bugs in the plasma and box parts. |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
I had a quick test with the binary, going from 3.0 b5 to 2.6k and from there on, and so far worked here (didn't test the IDE side yet). |
| |
soci
Registered: Sep 2003
Posts: 480 |
The IDE part is where it gets complicated. It's most useful when the card is split into a FAT and a native CFS partition, but setting this up can be a challenge. No one seems to read the manual at least.
Did you tried the other cartridges? I don't remember the details now (was some 8 months ago) but I think I've fixed FC3 freezing problems (maybe others too), some carts didn't masked ultimax properly (RR, SS5?) or had incorrect mapping (AR write through for example). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:No one seems to read the manual at least.
word |
| |
soci
Registered: Sep 2003
Posts: 480 |
Ok, not fully true as I've got at least one bug report when I've left a sentence in a manual by mistake which was not applicable to a newer version any more.
There are many questions about not being able to partition due to the write protection which is warned about in the third paragraph in the section explaining what to do with a blank disk.
CFSfdisk even warns that maybe writing was not enabled in the setup when it sees the error. But this doesn't help if the section explaining the setup wasn't read either.
Newer versions of CFSfdisk really try hard now to give working results even if one doesn't know what to do, which helps a little.
Also for some it's an insurmountable problem that the disk manager in windows does not allow partitioning of removable media for creating hybrid FAT/CFS disks. Solution is to use something else.
The last version now can bridge 2 disks as ATA master/slave instead of only one master. So there's less need for partitioning as one can be dedicated for CFS which is a bit easier to set up.
Anyway it's getting quite off topic now. Likely I'll open another thread later if I'll need more info for checking the read timing of the REU. But that has to wait as there are other things to do as well... |
| |
Digger
Registered: Mar 2005
Posts: 437 |
1 cycle raster splits in the sideborders? :D I see more REU demos coming in 2017. Together with PETSCII games obviously. |
