|
| |
Released At :
The 2015 REU Compo
Achievements :
C64 Demo Competition at The 2015 REU Compo : #1
Credits :
SIDs used in this release :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by Sith on 19 February 2018
Booze and HCL on steroids. Instant love from me. <3
It's a pimped demo but it still feels like a C64 demo.
All this stuff is wonderful. REU haters be gone! More please! |
User Comment
Submitted by Oswald on 29 September 2017
| bump. somehow I stumbled into this on YT, and boy did this grow. I guess its especially Dane's awesome tune, but also the smooth and flawless effects. hats down again. |
User Comment
Submitted by Burglar on 4 August 2016
just rebuilt vice and yep, the forreal1750 version now runs great, props to the vice coders.
and thanks to booze again for pushing the limit :) |
User Comment
Submitted by iAN CooG on 4 August 2016
VICE 2.4.29 now fixed to work with the TreuLove_ForReal1750Reu.d64, the previous version for older VICE now can be ditched =)
see the thread Reu test needed (real hardware) |
User Comment
Submitted by FATFrost on 14 July 2016
User Comment
Submitted by PAL on 11 July 2016
| RAUland of Telemark is a demo I would like to see one day! |
User Comment
Submitted by BHF on 11 July 2016
| Gotta love this REU one-filer ! Fantastic job done here guys. REU is great for certain types of demos, still got the true c64 feel from it. So fuck of REU-haters, eat your shorts ;) |
User Comment
Submitted by Bob on 7 April 2016
quite a lot of content in a one file demo, seems that there is a lot of generation going on in the background..
interesting.. eventhough I am not in to the reu...but still impressive. |
User Comment
Submitted by Cobra/Samar on 6 April 2016
User Comment
Submitted by willymanilly on 29 January 2016
Thanks Ruk for your feedback. I agree the colors in my emulator need some attention. I'll release a palette selector that recognizes .vpl files in my next release and look at changing the default colors. :)
The short answer to the 'hack' I did for the BA timing is as follows. Using Christian Bauer VIC-Article as a reference for VICII cycles, BA timing behaviour for the REU is normal for all VICII cycles except cycle 12 and 13. If there is any sprite DMA active at cycle 12 on a badline, the REU will execute it's cycle. The REU will always execute it's cycle at cycle 13 on a badline. The snippet of code from the REU part of my emulator that does this task is here. ==> if(maincpu.RDY||(reufix&&((vicii.viccycle.id==12&&vicii.spriteDMA!=0)||vicii.viccycle.id==13))){executeREU...}//reufix default value is true and changed via the REU menu
I suspect my model will only work for REU writes to the C64 and not the other way around. I don't have a real 1750 REU to test that but it should be an easy fix to the emulator if that is the case. |
User Comment
Submitted by ruk on 28 January 2016
@willymanilly: Great work with your emu, although the palette needs some lovin' :)
The sprite bug you mention is there on the real thing too afaik, so I think you got it just right! Now let the world know what you did so VICE can be properly updated! |
User Comment
Submitted by willymanilly on 24 January 2016
| Great demo! I love seeing the C64 being pushed to it's limits. I don't have a real 1750 to play it with but I have included a hack in my emulator to play the real 1750 version with sprites showing in border. @Groepaz, do you have any screenshots of how your test program should display on real hardware? If anyone interested my emulator is available http://www.z64k.com I know the GUI still needs a lot of work but it is very functional and stable. The REU features are available under the Expansion menu. I'm still investigating the REU BA timing discussed in this forum so any comparisons of my emulator from anyone with a real REU would be greatly appreciated. :) |
User Comment
Submitted by hedning on 13 January 2016
| Have anyone tested the demo on a REU larger than 512kb? Just curious. |
User Comment
Submitted by 6R6 on 8 January 2016
| Excellent! With the new fix, those scrollers also works on my 512kb Super 1750 Clone (c) 1991 Chip Level Designs. |
User Comment
Submitted by chatGPZ on 5 January 2016
| jackasser: unfortunately the REU stuff is very old code, none of the active ppl in the team worked on it (except some minor details that i fixed a while ago).... which doesnt really help with fixing it :( |
User Comment
Submitted by Radiant on 5 January 2016
| Nice. My only gripe is now I have a psychological expectation this is what a modern C64 demo should look like. |
User Comment
Submitted by HCL on 5 January 2016
Quoting nameAnyway, cudos to the VICE team and to Groepaz for having the REU-emulation as good as it is already. It could have been MUCH worse. :) Indeed, totally agree. This demo would *not* have been, if the emulation was not already there. The fun of finding a bug just adds the extra excitement you can not buy for money. |
User Comment
Submitted by JackAsser on 5 January 2016
| Anyway, cudos to the VICE team and to Groepaz for having the REU-emulation as good as it is already. It could have been MUCH worse. :) |
User Comment
Submitted by psych on 4 January 2016
User Comment
Submitted by GH on 4 January 2016
| Woow, great sruff and love this tune! |
User Comment
Submitted by HCL on 4 January 2016
| Hehe.. i guess that was Groepaz saying "ok, i was wrong" ;). |
User Comment
Submitted by chatGPZ on 4 January 2016
User Comment
Submitted by chatGPZ on 4 January 2016
"Seems like the reu manages to steal 2 cycles from the vic, just like the cpu does :)"
no certainly not, think again :)
like soci suggested, its a BA related problem. not only is there no difference between sprite 0 and the other sprites - also badline timing seems broken (i thought i had checked this too, but apparently not). i quickly knocked up a testprogram that does was soci suggested -> http://hitmen.c02.at/temp/spriteba.prg (press 1-8 to toggle individual sprites, 0 to disable all. dont look at the code =P). (maybe soci wants to peek at reu.c too.... some quick attempts at monkeypatching didnt quite work out hehe) |
User Comment
Submitted by Bob on 4 January 2016
Nice [reu] demo by the boozers...
where's Mirage? Since you took him from us he's doing zero ? not ok... then we'll take him back 8)=) |
User Comment
Submitted by soci on 4 January 2016
"So.. Guten Abend mr. Groepaz. I'm afraid you have to eat this one up. x64sc + reu is *not* 100% timing accurate, just eat it and swallow. Try the new DL file, and i hope you will also see those two sideborder-scrollers working, but totally failing in the emu. Seems like the reu manages to steal 2 cycles from the vic, just like the cpu does :)"
I believe that Groepaz did extensive testing. Those 2 cycles would show up very fast if you start a transfer cycle exactly on top of screen and check when it stops somewhere at the bottom (with bad lines of course).
However what I can easily imagine is that it was overlooked that the first line of sprite 0's DMA starts a bit later, and depending on the implementation of the REU this might lead to an extra write cycle at that point. This is also easily verifiable with the above method, but with sprites instead of badlines.
Anyone with access to a REU wants to verify this? In theory there should be a single cycle difference between using sprite 0 or sprite 1 on screen, while it's most likely identical on the emulation. |
User Comment
Submitted by hedning on 4 January 2016
| I tried it on my REU and the new file looks just fine! Good work HCL! Wonderful! Seems we got proof that emulation needs to be worked on. Oh, I also hope more people test it on their 512k REU:s. |
User Comment
Submitted by Dane on 3 January 2016
I'm most definitel biased but...
All hail the mighty HCL. |
User Comment
Submitted by HCL on 3 January 2016
Quote:as said, i verified the timing of all possible transfers, and they match 100%. So.. Guten Abend mr. Groepaz. I'm afraid you have to eat this one up. x64sc + reu is *not* 100% timing accurate, just eat it and swallow. Try the new DL file, and i hope you will also see those two sideborder-scrollers working, but totally failing in the emu. Seems like the reu manages to steal 2 cycles from the vic, just like the cpu does :).
The new file has been verified on only two setups so far, so i'm curious about other results. ..and please, reu is the targer hw. If any 1541U is not presenting a correct result, that is of minor interest. I think a 1750 reu + a variation of c64:s will give us enough deviance :). |
User Comment
Submitted by Dane on 3 January 2016
| Pal, it is labeled as such with [reu].. Anyway, as far back as August I asked for a separate category. :P |
User Comment
Submitted by PAL on 3 January 2016
| PS: Shoud this not be a REU demo in the category of type of demo? Is a one file demo a one file demo? I just had to ask as in my mind this is a one file demo but it is using REU... that is a bit confusing because it do give advantages over non REU demos? right? |
User Comment
Submitted by PAL on 3 January 2016
| Booze "SMOOTH" Design! yeahamiga! It just look and sound super... thanx for this splendid start of the new year and for giving Mr. Firefox competition on the REU alteration platform... Master Rolfsen, code like the wind!!! |
User Comment
Submitted by Burglar on 3 January 2016
this is the pinnacle of the c64 demo scene of 2015. no other release has caused this much doubt and uncertainty about how our beloved hardware really works. /me tips his hat
the x-rotator was the best part, but one question: did you aim for it to be in the sideborder too? the border clipping is the only minor gripe really ;) |
User Comment
Submitted by Dane on 2 January 2016
| That's the spirit. My friend HCL - eradicating bucs since 1991. |
User Comment
Submitted by HCL on 2 January 2016
| Everything looks 100% as is should except for the sideborder timing in those two parts. The bugs look very deterministic, but i'll be back after more investigations. |
User Comment
Submitted by Frantic on 2 January 2016
| @HCL: Just a word of caution. It was ages ago since I last used that REU, so I can't promise that it works 100% as it should. Didn't have problems with it in the past though. |
User Comment
Submitted by HCL on 2 January 2016
Quote:on my setup with real reu that sideborder scroller kindof works btw, just some lines are opened and some are not - exactly what you'd expect =) Oh, that's news to me.. I don't know what we're arguing about then.. I will try it myself on the real thing + a 1750 tonight, perhaps i'll find something else to argue about ;) |
User Comment
Submitted by 6R6 on 2 January 2016
User Comment
Submitted by chatGPZ on 2 January 2016
"Groepaz: I seriously doubt that the timing in x64sc reu is exactly the same as 1750reu."
as said, i verified the timing of all possible transfers, and they match 100%. the transfers take the time they should take, and the respective bytes are transferred in the cycle they should. also the register contents are what they should be after a transfer, including the odd special cases (that was verified years ago by wolfgang mosers testprog, which he btw wrote for 1541u checking) there is nothing to doubt, the testcode doesnt lie.
regarding 1541U - reading the registers works there, but they dont have the right value after transfers in all cases. timing is mostly ok however :)
on my setup with real reu that sideborder scroller kindof works btw, just some lines are opened and some are not - exactly what you'd expect =) |
User Comment
Submitted by Medicus on 2 January 2016
| \o/ Edge of Disgreuce \o/ |
User Comment
Submitted by hedning on 2 January 2016
| 6R6: Is that the "new" 1mb clone that uses an original 8726 REC? |
User Comment
Submitted by 6R6 on 2 January 2016
| Great demo! Just watched it on real hw. The Super 1750 Clone has the same border/sprite bug though. |
User Comment
Submitted by Joe on 1 January 2016
...or to put it more adequately using an emulator in the first place,
rocket science or not (yup that sideborder works none of the times and
when it decides to do in that emulator it rocks of ghost graphics for
more than one part!): What I see is what I get! ;D
Great demo and smooth effects combined with a lot of joy around the msx and gfx. |
User Comment
Submitted by ChristopherJam on 1 January 2016
Hmm, if writing to IO is that unreliable then my entry's probably also screwed. The colour writes are not so big a deal, but once a frame I dump in an entire VIC register set, including the next interrupt setup. Fixable, but I'll just keep my ear to the ground for now.
As for this release though, stunning work, especially if it can be bugfixed. Head and shoulders above the other entries in scope and style! |
User Comment
Submitted by HCL on 1 January 2016
Groepaz: I seriously doubt that the timing in x64sc reu is exactly the same as 1750reu. We know the sideborder-timing worx in x64sc, so what would be the exptected result if values written to $d016 were randomly corrupt? Mostly open sideborder with random gaps with closed border probably.. Not a constantly closed border, nor every second line opened like we have also seen on some setups. From what i have seen it looks like a stable timing, but not correct timing for opening the sideborder.. agree!?
Then about reading the registers.. well, i hope it would be reliable but i get reports of grabage graphics. Perhaps that was just from 1541U-users, and in that case it doesn't count :). |
User Comment
Submitted by Dr.j on 1 January 2016
| fuckin' awesome stuff delivered here..happy new year BD you amazing me time after time...keep cool guyz... great REU stuff! |
User Comment
Submitted by hedning on 1 January 2016
| Yes. 1541U2 is recommended. Chameleon fucks up badly, and real REU is not 100%. |
User Comment
Submitted by Almighty God on 1 January 2016
amaizing stuff, congrats mates...
Works smooth and nice in my C64C with 1541U-II v2.6h and REU to 512kbs |
User Comment
Submitted by chatGPZ on 1 January 2016
HCL: the general timing of the REU in x64sc is correct - as already said i made a lot of test programs a while ago and measured all possible operations. (i'll add those to the VICE repo in a while, still need to clean them up and comment a bit :))
the problem that shows here is simply that DMA from/to I/O is not reliable (even the REU manual states that iirc). depending on your REU, your c64, and possibly the phase of the moon, DMA to I/O will _sometimes_ write the correct value, $FF, or whatever was on the bus in the previous cycle. to make it worse, that behaviour is completely random and impossible to test for.
as a rule of thumb, you shouldnt DMA to I/O unless the value written isnt super important (like, writing a wrong value to d020 every now and then doesnt really matter). meaning that indeed a lot of interesting things cant be done - not reliable anyways.
oh, and all REU registers can be read. no problem there :) |
User Comment
Submitted by DKT on 1 January 2016
I never thought that REU can give so much more power to C64. Of course there must be someone to use it :-).
Firehawk - you've started it ;-).
This demo is what we always get from Boozers: code pr0n, quality&design, power and love... |
User Comment
Submitted by Shadow on 1 January 2016
| Just ran the demo with my 1541u2 set to 512kB REU instead of 16MB - that made the bugs in most of the parts disappear, only sideborder parts still don't work and that is explained by HCL below I think. |
User Comment
Submitted by HCL on 1 January 2016
Ok, i would like to shed some light on the different mentioned issues with this demo from what i know.
First.. all parts with text are so called generator-parts. They generate graphics, colors or other stuff that is used in the following effect-part (plasma, twister etc..). The visuals in the generator parts (text..) typically run in a short interrupt, and the main program does the generating. Now, the visuals in the generator parts utilize the REU as well, so in order to do that all relevant reu-registers have to be saved in the beginning of the interrupt and restored before return. Knowing that, it is easy to conclude that if you experience crap graphics in some of the effect-parts, it is probably because the REU is not presenting correct register values for reading. ..something that has been mentioned here already.
This Crap graphics bug is fixxable. Normally when entering an interrupt you have 7-8 cycles jitter. The generator parts typically transfer 32-40 bytes at a time, adding up to 40 cycles to the jitter. If you want a stable raster you have to handle that of course. By adding SEI/CLI around the transfer-operations in the generating code there would be no need to save and restore reu-registers in the interrupt, and that would solve the crap-gfx bug, though adding another number of cycles to the jitter.
Further, if sideborder timing is not working (in the two sprite-scrollers..) it is because there is a timing mismatch between real hw and vice x64sc reu-emulation. I found a way to remove sideborders with the REU that perhaps only worx on emulator. Lame, totally lame. Perhaps it is still possible, but with a slightly different timing. I always test my demos on real hw before release, but this time i was not able to. Ruk made some tests on 1541Uii, that's all we had.
The tiny bug at the top right of those two scrollers is just the very common sideborder-sprite bug appearing on many DYSPs from the old times. I was able to remove it on the first scroller before i made it move up/down, but when the sprites start on a badline, the bug could not be removed. ..just try to live with it :).
Well, it has been some great fun finding out a few new ways to use the REU. While emulation will probably get better over time, it feels troublesome if different REUs show different results. Perhaps the REU is not a stable enough platform to develop demos for at all? Hopefully some kind of standard can be set where things are reliable, but at least i think all versions of the c64 must show the same result with the same REU. Time will tell, i'm sure about that.
Finally, we *will* try to fix this demo to work on real hw. The 1750 REU is the target for this demo and nothing else. Don't expect it very soon though, we don't have the hw ourselves (yet) and i think several individuals have to be tested. |
User Comment
Submitted by hedning on 1 January 2016
| MaD ][: We need a good diagnostics program for REU:s. I have two faulty REU:s I want to fix. And I want to check my working one as well. |
User Comment
Submitted by MaD ][ on 1 January 2016
| @hedning: actually my real 1750 needs some fixing (test reports a couple faulty ram chips)... in the meantime emulated REU make my day anyway! |
User Comment
Submitted by Tom-Cat on 1 January 2016
WOW, thats how one utilizes REU :) Great production. And all that in a single PRG.
No bugs on my c64c and the old breadbin using 1541u2 here. Runs perfectly on both of them. The only little glitch I can see is the same on x64sc - the first sideborder scroller has a one line glitch on the right border area. That's all. |
User Comment
Submitted by Stone on 1 January 2016
User Comment
Submitted by Magic on 1 January 2016
Cool demo..
Now where can i buy a Reu ?
also indeed a seperate Reu demo categoree on csdb would be nice! |
User Comment
Submitted by taper on 31 December 2015
I was asked to test on my hardware, so I did. Used a C64C, and with 1541U-I (firmware 2.4A) it bugs a little (mainly the sideborder scroller, but also some glitches in other parts). On 1541-II (firmware 2.6j) it's the same. Then I switched to an oldschool REU, and the sideborder scroller bugs even more on that one. No bugs visible in the plasma parts, though, but some other glitches in various parts.
No doubt this is awesome code-pr0n, but I hope it can be fixed so it runs 100% on real machine too! I'm happy to test on other C64's too if it's of any help. |
User Comment
Submitted by Conjuror on 31 December 2015
| Love the blurry super colourful plasma and the wall of continuous bobs. |
User Comment
Submitted by Oswald on 31 December 2015
| still this is record setting if you excuse me, but indeed awesomely brilliant I dont wanna take that away sir :) |
User Comment
Submitted by Dane on 31 December 2015
| Oswald, of course. We were still the first to abuse that hw-expansion in the right(wrong?) way in order to do it. :) |
User Comment
Submitted by lemming on 31 December 2015
| Seriously tho... a 49.5kilobytes single-filer that uses 512K, this is some Amiga-killer type of shit right here hehe :D oh and happy new year everyone! :) |
User Comment
Submitted by Oswald on 31 December 2015
"there is still 9(?) recordbreaking screens crammed into a 5-minute demo here."
you are forgetting that it is done with the help of a HW expansion. |
User Comment
Submitted by iAN CooG on 31 December 2015
| YT 50fps hq capture provided by Lemming |
User Comment
Submitted by Testa on 31 December 2015
what must i say.. what are the right words. hmmmm hmmm there are no words..
f*cking amazing!!... thanks for this nice suprise... i am absolutly a big fan of this non standard compos and productions.. i think every thing of the c64 must be investigated... |
User Comment
Submitted by Digger on 31 December 2015
This is just brilliant (despite the bugs!) The timing (last day of the year and FPPs) and the Treu Love logo kicks my arse hard!
Happy 2016 to the unbeatable BD crew and You! <3 <3 <3 |
User Comment
Submitted by hedning on 31 December 2015
| HCL: Something wonderful. |
User Comment
Submitted by HCL on 31 December 2015
| omg.. what have we done? :D |
User Comment
Submitted by hedning on 31 December 2015
| Groepaz: If there was no bug in the emulation it would behave exactly like it does on real hw. ;) Just my 5c. Happy nude rear! |
User Comment
Submitted by Dane on 31 December 2015
| Treu Love - the reu-killer! Happy New Year. :) |
User Comment
Submitted by chatGPZ on 31 December 2015
darn. looks like my REU broke - the GP demo worked last time i tried, and now it doesnt either. fuckthefuckingshitfuck!
@brush: in fact, i am pretty confident that there is no bug in the emulation - because i have already written elaborated test programs for everything the REU can do and VICE passes all of them (and neither 1541U nor chameleon does, if anyone gives a damn). ... and demos are generally no good testcases, because they are doing too much at once and dont give a clear indication whats wrong either, so hardly useful for debugging anything. |
User Comment
Submitted by Smasher on 31 December 2015
amazing demo!!!
I think CSDb needs a new "REU demo" category. IMHO it's not enough to just tag [reu] in title. |
User Comment
Submitted by hedning on 31 December 2015
| Said that I want to say this demo kicks every other REU demo's ass, even with the bugs. :D Dane: <3 |
User Comment
Submitted by hedning on 31 December 2015
| MaD ][: Well. Emulated REU is not what counts here. |
User Comment
Submitted by Brush on 31 December 2015
@groepaz: i don't want to start a big discussion here :) Buuuut i think it looks like a first demo that is pushing REU really hard. So once it's fixed it will be indeed a great test case :)
If we want to super precise here one could also say that it should bug in the same way on vice as on the real thing :) |
User Comment
Submitted by hedning on 31 December 2015
| Just tried it on my Chameleon - don't do that - complete mess. :O Looking good on my first 1541U2 with black buttons (firmware 2.6k), except there are no sprites at all in the border in the last borderscroller before the credits. On my second 1541U2 with red buttons (firmware 2.6k) have the same result. First part bugs out severely on my 1541U Plus (firmware 1.7B), but after the first borderscroll (which is not in the border) it hangs completely. Will continue with my original REU - all parts look good there except the sideborder scrolls. |
User Comment
Submitted by MaD ][ on 31 December 2015
| just got it runnung on real C64+1541U2 (with FW 3.0b5)... disabled everything other than 512K REU et-voilà: G-R-E-A-T! straight 10 from me! |
User Comment
Submitted by lemming on 31 December 2015
Oswald>remember that 1541u is just another emulator.
agreed. btw with 1750 I got some real funky fart-sounds on the decrunch, those ruled :D they weren't there with the 1541u2 tho :o |
User Comment
Submitted by chatGPZ on 31 December 2015
some nice stuff here.... however it not working correctly on real hardware is a big minus for me. (tested with C64C and 1750, lots of bugs in each part).
(brush: not a good testcase for VICE unfortunately if it doesnt work right on the real thing =P) |
User Comment
Submitted by Oswald on 31 December 2015
| remember that 1541u is just another emulator. |
User Comment
Submitted by lemming on 31 December 2015
| ohh, I think I got it working properly now. switched 1541u2 from 16MB to 512K. or possibly the stars were ccorrectly aligned when I pressed the return key on RUN this time :) |
User Comment
Submitted by lemming on 31 December 2015
| I was hasty. 1541u2 REU seemed to introduced some other glitches (on the plasmas and the texturerotators) |
User Comment
Submitted by lemming on 31 December 2015
| on a real C64 the sideborder scrollers are bugging with a stock 1750REU and a 1MB REU, but switching to the 1541u2's REU seemed to fix that. great show! |
User Comment
Submitted by hedning on 31 December 2015
| And by help I mean: I want this to be THE reu-demo, because it is that awesome!11 |
User Comment
Submitted by hedning on 31 December 2015
| I'll do some more runs now, as my wife is busy in the kitchen for some hours (I bought a goose that needs to be eaten this evening). Will try my three 1541U:s and some more runs on my real REU. I'm doing this to help. Will send Ruk some movies and pics for analysis. I bet Lemming and Taper can help out too on real hw. |
User Comment
Submitted by Shadow on 31 December 2015
On my real C64+1541U2 REU I get bugs in many other parts as well, all the plasmas for example are filled with garbage graphics.
Might be the 1541U2 that is not REU compatible enough though. I for one will hold off on casting any vote until I get to see the demo as it should look. (and no, emulators doesn't count - real HW and CRT monitor is the only way! :D) |
User Comment
Submitted by Dane on 31 December 2015
Well, there will never be any justice to these ratings, but disregarding the eventual sideborder bug there is still 9(?) recordbreaking screens crammed into a 5-minute demo here. :) The magic of Hcl and Ruk! <3
(And yay to me for actually coming up with that fpp-idea!) |
User Comment
Submitted by iAN CooG on 31 December 2015
| I have voted based on what I have experienced using x64sc+reu512k, I can understand that if someone can't get it fully working on real c64+real reu can vote it less, and luckily they didn't gave less than 5 =) |
User Comment
Submitted by Wisdom on 31 December 2015
| What's next, complaining about 9s? |
User Comment
Submitted by Dane on 31 December 2015
Wow, 2 people rate this a 7? Really looking forward to their REU demos. :)
Thanks to everybody who likes this. We're in love with all of you! <3 |
User Comment
Submitted by Shadow on 31 December 2015
| Don't know how accurate the REU implementation in the 1541U2 is, but the demo shows quite a lot of bugs for me using that one too at least. |
User Comment
Submitted by ruk on 31 December 2015
The technical reference may shed some light:
Quote:
3.3 Unreliable DMA transfers for I/O area exchanges with the REU
...
From observations with testing the REU controller for all the features and behavior described in this document it needs to be said that the REU does not operate fully stable when transferring to or from the C64/C128 I/O area in the range from 0xD000 to 0xDFFF. The grade of transfer instability depends on the actual C64 or C128 mainboard revision. When doing data transfers from the main computer into the REU, then for older models some byte every 200 to 1000 bytes is copied wrong.
Actually not the byte value in its own gets corrupted, but the REU controller is not able to address the correct byte. It just takes another one from the C64/C128's I/O area instead.
The transfer reliability with the I/O area also seems to depend on the operation mode done. Verify operations were a lot more unreliable than simple transfers. Verify operation with both addresses being fixed could be used to watch a decent I/O area register to change its value. If the register does not change like with the sprite X register for example, then the REU should count down until the transfer length register reaches value 0x0001. But only, when the value within the REU was programmed to the same value before.
With the REU reliability bug, the REU controller does not count down to 0x0001 in most cases and on all tested C64/C128 mainboard revisions27. Often only 20 verify operation cycles were done until a non existing verify error was detected.
http://zimmers.net/anonftp/pub/cbm/documents/chipdata/CSG8726Te.. |
User Comment
Submitted by Brush on 31 December 2015
| @HCL: Actually you might have just created a nice test case for vice :) |
User Comment
Submitted by HCL on 31 December 2015
| Yep, we released it despite the known bugs. Noone of us have a real REU, it has all been developed using x64sc. When ever i can get hold of a reu i will look into those issues of course :). |
User Comment
Submitted by hedning on 31 December 2015
| EDIT: What I tried to say: If it's NOT my REU that bugs (I ran it four times with the same result) I hope it's easy to fix. :) |
User Comment
Submitted by hedning on 31 December 2015
I'm sorry to say there might be some bugfixing still needed. Have someone actually tested this thing on a real REU before hitting the 10? All in all it's a GREAT demo - I flew off my data chair this morning, probably worth a 10 even with the bugs, but I ran it on my REU, and I would like someone else to do the same, to test if it's my REU that bugs, or if it's the demo. If it's my REU that bugs (I ran it four times with the same result) I hope it's easy to fix. :)
 |
User Comment
Submitted by Firehawk on 31 December 2015
| Great one-file demo by Booze. Love the REU stuff you did here. |
User Comment
Submitted by Brush on 31 December 2015
This is ACE :) What one can do with FPP when there are no limits to the amount of gfx moved around. I also liked the unlimited bobs part (how many frames HCL? 50?) - for a brief moment with the first movement i thought this is still a DYSP part :) Very nicely done with the usual attention to detail. The only (first world) problem with this demo is that in the "Edge of Disgrace" fashion - once HCL found a technique ("reu fpp") he exploited it in so many ways that he left little space for the followers :)
Thank you for a great post-xmas gift guys!
Small note: is it only my vice or the sideborder scroller bugs on the right side (there is a line roughtly 1 sprite wide and 1 pixel high that shows from time to time). |
User Comment
Submitted by Neo-Rio on 31 December 2015
| Oh wow. Never seen anything this amazing. Just shows what an REU can do for you. I have the emulator on warp for the endless balls bit :) |
User Comment
Submitted by Trap on 31 December 2015
Very nicely done. Excellent coding skills! Congratulations guys.
This definitely paves the way for more REU demos in the future, but also begs the question whether there should be a seperate category for this kind of demos (REU, DTV etc.) here on CSDB. Pears and Apples. |
User Comment
Submitted by Shine on 31 December 2015
| I am always skeptic with this REU story ... B U T this is just amazing! <3 10/10 Thanks a lot!!! |
User Comment
Submitted by Oswald on 31 December 2015
| I seriously thought fpp like stuff is not possible, but holy fuck it is, w.o.w. thank you :) |
User Comment
Submitted by Rock on 31 December 2015
User Comment
Submitted by WinstonSmith6079 on 31 December 2015
Good stuff, man hehehehe
Gonna make an .RP9 for it hehehehe |
User Comment
Submitted by Perplex on 31 December 2015
User Comment
Submitted by Pantaloon on 31 December 2015
User Comment
Submitted by Yogibear on 31 December 2015
User Comment
Submitted by iAN CooG on 31 December 2015
| vice users: make sure to use x64sc =) |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs (1)
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Info on other sites | |
|
| Support CSDb | |
|
 |  |
|
9.4/10 (59 votes) 