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 > CSDb Entries > Event id #2391 : The 2015 REU Compo
2015-07-25 13:54
taper

Registered: Dec 2001
Posts: 119
Event id #2391 : The 2015 REU Compo

Welcome to the 2015 REU Compo --- Hosted by LFT, Ruk and Taper!

See the event-page on: The 2015 REU Compo

Your mission is to create the most awesome one-file demo that runs on a standard C64 with a 512 kB REU and no disk drive.

Background
==========

The Commodore RAM Expansion Unit (REU) is a cartridge that provides secondary storage to the C64. It was introduced at CES in 1985. The memory in the REU cannot be accessed directly from the CPU (hence
"secondary"). Instead, the CPU must instruct the REU to transfer a given amount of data to or from the cartridge. The REU then takes over the bus, stalling the CPU, and transfers one byte per cycle.

This is basically all there is to it. Apart from the extra storage, the REU does not make the C64 faster or more powerful---although see below for some intriguing possibilities.

The largest REU available from Commodore (the 1750) was equipped with 512 kB of RAM. Nowadays, it is possible to emulate REUs with as much as 16 MB, e.g. using VICE or the 1541 Ultimate. Even though you can only use 512 kB in this competition, there should be no problems using
the RAM expansion features in the 1541U/1541U-II, Chameleon64 or any other device fully compatible with the Commodore 1750 REU.

Rules
=====

1. Your entry must be in .PRG format with a BASIC header. The file must load to address $801, and end before it reaches the I/O area at $d000. The gives a maximum file size of 51201 bytes.

2. You may assume that a REU of at least 512 kB is available.

3. Your entry must work with a larger REU (i.e. you cannot assume that the upper address bits are ignored). You may not use the extra RAM available in such configurations.

4. You cannot make any assumptions about the initial contents of REU memory.

5. Your entry must work on a real C64 with a real 512 kB REU from Commodore. Please keep in mind that there could still be bugs in the emulators.

6. Deadline is set to 2015-12-31 at 23:59 in a time zone of your choice. Your contribution needs to be mailed to reu@wuff.se to be accepted. You are free to create a CSDb entry for your contribution, else we will do it for you.

7. Immediately following the deadline, voting will take place on CSDb during a period of two weeks. Anonymous votes will be counted. We allow self-voting unless you have multiple personalities.

Suggestions
===========

For your inspiration, here are some ways in which a C64 demo might benefit from an REU:

Obviously, the extra RAM is useful. For instance, the demo might pre-compute large amounts of sprite graphics, and then quickly retrieve a subset of the data just before it's needed.

The fast transfer rate could be used to speed up scrolling operations: You can copy a large bitmap from the C64 to the REU, and then back again at a slightly different address.

Last but not least, the REU has a mode where every byte in a transfer gets written to the same destination address. This can be used to display graphics using the idle byte, for instance. The target address
could also be an I/O register, and this might enable some new VIC tricks.

Technical information
=====================

Please refer to the following documents for details about the REU programming interface:

http://www.zimmers.net/anonftp/pub/cbm/documents/chipdata/progr..

http://codebase64.org/doku.php?id=base:reu_registers

Happy hacking!

/LFT, Ruk & Taper
2015-07-25 19:17
chatGPZ

Registered: Dec 2001
Posts: 11390
you forgot CSG8726R1-TechnicalReference-1.0.pdf - which is pretty much the only (mostly) complete and error free doc :)
2015-07-26 08:50
ruk

Registered: Jan 2012
Posts: 43
Thanks, Groepaz!
2015-07-26 14:32
Maxlide

Registered: Apr 2003
Posts: 32
How are you supposed to get your data into ur machine without a diskdrive? Oo
2015-07-26 14:57
iAN CooG

Registered: May 2002
Posts: 3201
tape! apart that, after loading the prg should run with the drive turned off, i guess.
2015-07-26 15:20
chatGPZ

Registered: Dec 2001
Posts: 11390
MSE - obviously!
2015-07-26 15:49
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
i thought we were discouraged from uploading PRGs here... can the rules have a likkle nudge so T64 is okay too? =-)

(Also... considering options and wondering if the TC's REU is close enough to trust when developing.)
2015-07-26 16:05
chatGPZ

Registered: Dec 2001
Posts: 11390
we are working on that just right now =)
2015-07-26 18:13
Oswald

Registered: Apr 2002
Posts: 5095
whish the reu was just a little bit more programmable, fex skip every nth byte would help in doing a twister. iirc we had a topic where it was said reu could get rid of the fli bug, well now is the time :)
2015-07-31 13:31
JackAsser

Registered: Jun 2002
Posts: 2014
When the VIC needs to steal cycles for DMA, will the currently running REU-DMA simply be halted and resumed after the VIC-DMA? Will the VIC also stall the REU an additional 3c like it does when stalling the CPU?
2015-07-31 17:49
Krill

Registered: Apr 2002
Posts: 2981
Quoting JackAsser
When the VIC needs to steal cycles for DMA, will the currently running REU-DMA simply be halted and resumed after the VIC-DMA? Will the VIC also stall the REU an additional 3c like it does when stalling the CPU?
Afaik, yes. The REU is very BA-shy, it halts as soon as BA goes low, and does not use the 3 possible write-cycles. Then it continues when VIC-DMA is done. Only heard this, though, and have never confirmed it.
2015-07-31 23:32
Trash

Registered: Jan 2002
Posts: 122
Quote: When the VIC needs to steal cycles for DMA, will the currently running REU-DMA simply be halted and resumed after the VIC-DMA? Will the VIC also stall the REU an additional 3c like it does when stalling the CPU?

It will be halted and then resumed after the VIC-DMA is finished (I verified this during my shortlived idea of 40 columns of FLI)...
2015-08-01 00:00
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: It will be halted and then resumed after the VIC-DMA is finished (I verified this during my shortlived idea of 40 columns of FLI)...

Yeah, trying to use the REU on a bad line is a bad idea... :)
2015-08-02 08:57
Firehawk

Registered: Aug 2011
Posts: 31
Yes the VIC will take the bus from the REU when it needs to (try streaming lots of data to $d021 when display is enabled) - this is also seen if you try to make i.e. $d020 splits and have sprites on the screen (this is a good way to understand where and when each spritecombination halts the bus - I would advice using VICE in border=debug to see this).
Another thing that is possible though (although not FLI, but close) would be to stream to $d021 during the non-badlines, which would add some color freedom.
2015-08-02 11:30
Dane

Registered: May 2002
Posts: 423
A CSDB REU category would be nice. If not, I'm sure the onefile-demo chart will look different next year.
2015-08-03 14:16
Rastah Bar
Account closed

Registered: Oct 2012
Posts: 336
Bit off-topic, but have you seen this cool REU project?

http://dragonslair64.areaaperta.com/
2015-08-03 14:36
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Quoting Dane
A CSDB REU category would be nice. If not, I'm sure the onefile-demo chart will look different next year.


Yeah, that's a very good point...
2015-08-04 10:34
Slammer

Registered: Feb 2004
Posts: 416
Really interesting compo, and good limitations.

Does anybody know how well tested the VICE emulation of the REU is? Is it cycle exact? If we are going to make VIC-timing effects this is critical. How many have an actual REU so they can test their productions?
2015-08-04 10:50
JackAsser

Registered: Jun 2002
Posts: 2014
We've done some cycle exact tests in Booze and so far Vice, x64sc latest version has delivered correct behaviour. I'm sure there are flaws, but the obvious REU-parts, like FPP variants and the like seems to work.
2015-08-04 12:07
chatGPZ

Registered: Dec 2001
Posts: 11390
recent VICE passes all known testcases .... and no other emulation does so far, so better have a real REU handy for testing on the real thing :)
2015-08-05 08:26
ChristopherJam

Registered: Aug 2004
Posts: 1409
I thought we pretty much agreed over in When is a One-File Demo not a One-File Demo? that the one-file category was for entries fitting Krill's definition:

Quoting Krill
Classic onefilers are up to 202 blocks, $0801-$cfff, and load in a single pass before running, no autostart, no tricks, no disk images.
2015-08-05 09:43
Burglar

Registered: Dec 2004
Posts: 1105
"no tricks", in my book that includes not adding a reu.
2015-08-05 09:50
Frantic

Registered: Mar 2003
Posts: 1648
I suppose it refers to no tricks regarding the loading of the file?
2015-08-05 12:01
ChristopherJam

Registered: Aug 2004
Posts: 1409
...and of course Krill's rule is already covered by the very first rule of this compo.

FWIW, in the thread linked algorithm was suggesting one-filers also require no additional hardware. Maybe we just need more explicit category names?

In any case, cool compo. I was going to pass on this one, but I'm starting to get ideas now. Stupid brain..
2015-08-05 16:20
algorithm

Registered: May 2002
Posts: 705
What about a Turbo Chameleon compo. The cartridge can allow its features (turbo cpu etc) to be turned off on from within the c64 side. Has there been any demonstrations specifically done to take this into account?
2015-08-05 22:34
Moloch

Registered: Jan 2002
Posts: 2929
If anything CSDb needs less categories and credits options
2015-08-08 07:27
FATFrost
Account closed

Registered: Sep 2003
Posts: 211
i love the turbo but it's cheaper for me to buy a laptop and run vice and get all the same features. ;)
2015-09-22 21:47
chatGPZ

Registered: Dec 2001
Posts: 11390
After doing more tests i can tell that x64sc (NOT x64!) from VICE is actually pretty accurate for REU stuff - other emulations not so much (yet?) :=)
2015-09-23 06:49
Firehawk

Registered: Aug 2011
Posts: 31
Yes Groepaz is correct. We had problems with Qi on the x64, it apparently has a problem with real-time streaming of data into memory (i.e. $3fff pictures and 40+ rastersplits etc). The x64sc works perfectly, the entire demo was developed under emulator and tested on 1541U2 without any glitches.
2015-09-23 08:53
chatGPZ

Registered: Dec 2001
Posts: 11390
in x64 the timing is often wrong by one cycle, as the DMA/BA behaviour is not cycle exact.
2015-09-23 16:24
Dane

Registered: May 2002
Posts: 423
Good good, I'd hate for all those parts-in-progress to be done in vain. :)
2015-09-23 16:31
ChristopherJam

Registered: Aug 2004
Posts: 1409
Thanks for the heads up - I've been testing in the wrong one...
2015-09-23 19:07
Count Zero

Registered: Jan 2003
Posts: 1940
Firehwak: cough cough - a REAL drive should be the base testing ground. Definately not 1541Uanything.

Just my 2 cent.
2015-09-23 19:14
chatGPZ

Registered: Dec 2001
Posts: 11390
also REU emu in 1541u is _not_ entirely correct either!
2015-09-23 20:01
insane

Registered: Nov 2006
Posts: 10
@Groepaz: but according to the chameleon bug list
"DMA transfers take 1 cycle more than they should"
which really screws up timing dependent code.
I did a simple reu 4bit wave player with screen off +
D020 changing as timing test - x64sc shows some rock stable
raster colors as well as 1541u2 - but on chameleon the
timing goes haywire.
So which timing should i follow - or will that "bug" be fixed soon?
just asking as I'm working on a small 15khz audio +
mcol video player which only syncs once per frame
2015-09-23 20:17
chatGPZ

Registered: Dec 2001
Posts: 11390
yes, chameleon is also still broken (we are working on it :))

and obviously your reference should be neither, use a real REU for testing.
2015-09-24 11:12
ruk

Registered: Jan 2012
Posts: 43
@Groepaz: Can you elaborate on the 1541u topic?
2015-09-24 12:19
chatGPZ

Registered: Dec 2001
Posts: 11390
in some border cases the register contents after a transfer are wrong, that may be a problem if you don't rewrite all of them before each transfer.
2015-09-24 17:07
Firehawk

Registered: Aug 2011
Posts: 31
@Groepaz: is that 1541u or also 1541u2? I know Qi does not work with 1541u, but works perfectly on 1541u2, real REU and ofcourse x64sc (not tested on chameleon afaik). My experience is that the REU-emulation of x64sc is very reliable.
2015-09-24 17:10
chatGPZ

Registered: Dec 2001
Posts: 11390
its probably the same on 1541u and u2 (i have not done extensive testing with both, i mostly use u2 recently).

x64sc is indeed pretty accurate, as said (all of my testcases work so far)
2015-10-06 13:32
Shadow
Account closed

Registered: Apr 2002
Posts: 355
I did not quite get from the rules if entries were to be mailed and then released by the organizer after dec 31, or if we can mail them but also add them to CSDb right away?

I have a little something that is almost done, and I think that by adding it to CSDb sooner than waiting for the compo deadline it might get more people motivated to make their own entries (the good old "pff.. that's lame, I can do MUCH better using the REU").
2015-10-06 20:30
Dane

Registered: May 2002
Posts: 423
Current state: a few preview parts, no gfx or art direction, no soundtrack. Some motivation would be nice. :)
2015-10-06 21:05
Stinsen

Registered: Feb 2012
Posts: 77
Quote: Current state: a few preview parts, no gfx or art direction, no soundtrack. Some motivation would be nice. :)

Dane? No soundtrack? My eyes must be playing me a joke. :D
2015-10-06 21:45
Dane

Registered: May 2002
Posts: 423
It's only October!
2015-10-13 11:04
lft

Registered: Jul 2007
Posts: 369
Quoting Shadow
I did not quite get from the rules if entries were to be mailed and then released by the organizer after dec 31, or if we can mail them but also add them to CSDb right away?


Official statement from the organisers: Yes, it is OK to publish and add a release to CSDb before the deadline.

If you publish now, but wish to compete with a different version that you mail to us later, it might be a good idea to clarify this in your mail. Just so we don't mix up the versions.

Thanks for participating!
2015-11-05 11:56
Shadow
Account closed

Registered: Apr 2002
Posts: 355
Did someone have a chance to test run my entry (Reutozoom)on a real REU?

I developed it using WinVICE and testing on my C64 with 1541U2, and never had any problems.

Then when showing it on the Mysdata gathering, Hedning had managed to find a 512kb REU, so we could run it on real vintage hardware, and it worked fine.
However, later that night after some more people had arrived, we tried it again, and then there were strange bugs, to me it looked like one bit per byte had garbage data, but only for the top half of the memory!
Resetting and reloading didn't help. We unplugged the REU and tested with a 1541U2, and it worked fine again.
Later we plugged in the REU again, and then it worked.
We chalked it up to faulty hardware, since it seemed to run fine when the REU had some "rest" to cool down.

Anyway, it still would be good to know that this is the case and it's not me having done something stupid in the code.
2015-11-05 12:18
Grue

Registered: Dec 2001
Posts: 162
Commodore sold REU's with beefier psu, I think for a reason. Did you have better psu when you tried running with real REU?
2015-11-05 16:10
Shadow
Account closed

Registered: Apr 2002
Posts: 355
You might be on to something there! I don't know if that C64 was running with just a standard power supply, but I think there's a big chance that it did.
2015-11-06 06:16
hedning

Registered: Mar 2009
Posts: 4732
What?! You know me better than that, Shadow. ;) No way I ran it on a standard PSU - haven't done that for 1 year now. It ran on a Ray Carlsen PSU, which should have enough cream to run a SuperCPU at least (according to the specs). It is well known for being the best PSU around. What could be the issue is that the REU is indeed old and could be flakey - it is Walker's old modified (expanded) REU, upgraded to 1MB (I think). I haven't really used it for anything else. I will try the demo again a couple of times today (I'm home from work anyway).
2015-11-06 10:41
Shadow
Account closed

Registered: Apr 2002
Posts: 355
My deepest apologies - I should not doubt your excellent hardware collection! :)
2015-11-06 11:09
hedning

Registered: Mar 2009
Posts: 4732
Quote: My deepest apologies - I should not doubt your excellent hardware collection! :)

Haha. No prob... But anyway. Will give you some more feedback after some rounds here at home.
2015-11-06 12:21
hedning

Registered: Mar 2009
Posts: 4732
Ran the demo 7 times today... Got bugs the first time, but not on the 6 following runs (with hard reset between them). I would say it works just fine, and the bugs comes from the cold REU. When it warmed up, everything was fine.
2015-11-06 14:08
HCL

Registered: Feb 2003
Posts: 728
..but you said that during party conditions, it had to cool down(!).. Hmm, well. Perhaps it makes sense after all :P
2015-11-06 14:31
bugjam

Registered: Apr 2003
Posts: 2594
Quoting hedning
...it is Walker's old modified (expanded) REU, upgraded to 1MB (I think)...


Could that not be the reason?
2015-11-06 15:29
hedning

Registered: Mar 2009
Posts: 4732
Could be. IF it is expanded. I have no clue how to check that.
2015-11-06 19:31
hedning

Registered: Mar 2009
Posts: 4732
It's a 1764 REU - and I opened it up. It is expanded. From 256 to 512 kb.
2015-11-08 08:26
Count Zero

Registered: Jan 2003
Posts: 1940
hedning: I own a CMD clone REU with 512kb which Sorex sold to me a long time ago. The RAM chips are bugged and any first run of a test program will give wicked results. Any other runs on plain warm resets will work. Power off for some time will make the "broken" effect come back on this one.
2015-11-08 16:22
hedning

Registered: Mar 2009
Posts: 4732
Quote: hedning: I own a CMD clone REU with 512kb which Sorex sold to me a long time ago. The RAM chips are bugged and any first run of a test program will give wicked results. Any other runs on plain warm resets will work. Power off for some time will make the "broken" effect come back on this one.

Seems like this is exactly the case here. Thanx.
2015-11-21 16:21
Smasher

Registered: Feb 2003
Posts: 521
I had a REU, I think it was the 256kB model. I should check one of those boxes in my cellar, perhaps I'll find it.
I used it 25 yrs ago for swapping, as with that thing it was possible to copy a whole disk in one go and very quickly!
I never used it for anything else, like coding... lame me!
the compo is tempting, I should better follow those links and read some technical docs and then see if I can understand something and decide to take part...
some lame questions (feel free to answer RTFM!, have no mercy with me!):
- if I have my stuff (e.g. bitmaps) packed in the c64 memory is it possible to directly depack it in the REU memory? or should I cache the depacked thing in the c64 memory first and then move?
- how much data can I move from REU to c64 in a frame with screen on?
thanks for helping. more questions will probably follow... :)
2015-11-21 16:35
chatGPZ

Registered: Dec 2001
Posts: 11390
a) not possible (without a lot of overhead anyway), since REU memory isnt memory mapped
b) exactly 1 byte per cycle, plus ~20 or so overhead maybe for the setup (calculate yourself =P)
2015-11-22 14:07
Firehawk

Registered: Aug 2011
Posts: 31
about 18600 bytes/frame
2015-11-22 19:59
Oswald

Registered: Apr 2002
Posts: 5095
more than enough to animate koala at 50fps
2015-11-22 22:21
Smasher

Registered: Feb 2003
Posts: 521
thanks guys for the answers!
2015-11-22 22:44
Smasher

Registered: Feb 2003
Posts: 521
if this wasn't posted before... REU-Colors
it's of course no crest or hoaxers megacool REU demo, but it contains the source with comments, so now it's quite clear to me how to store data in reu banks and how to move them back to c64 ram.
for those who are at my level, i.e. moving the first steps in the REU world, I think it will help.
2015-11-23 08:33
Firehawk

Registered: Aug 2011
Posts: 31
If this would help or inspire, the entire FRONTIER source is found here (although comments are lacking).

Frontier
2015-11-23 21:55
Smasher

Registered: Feb 2003
Posts: 521
uff Firehawk... I had a look at your source files and now I feel like I'm still in the kindergarten of coding school again :)
congratz! and greetz from ze spaghetti coder #1 :)
2015-12-15 20:06
lft

Registered: Jul 2007
Posts: 369
Just a friendly reminder to get your releases in shape for the compo. Deadline is 2015-12-31 at 23:59 in a time zone of your choice. Happy hacking!
2015-12-15 21:07
Count Zero

Registered: Jan 2003
Posts: 1940
I volunteer for testing - promising not to pass any bits of data or information to anywhere. Can't - wait - for - stuff - here ...

Will test on my extra buggy "Sorex-REU" (CMD 2MB clone) with RAM initalisation bug as well as on a 1541U1 with 1.72 firmware - in case you wonder :)
2015-12-15 21:54
Dane

Registered: May 2002
Posts: 423
Quote: Just a friendly reminder to get your releases in shape for the compo. Deadline is 2015-12-31 at 23:59 in a time zone of your choice. Happy hacking!

Christmas holidays are saved...cause we're still short on gfx. :)
2015-12-27 21:46
ChristopherJam

Registered: Aug 2004
Posts: 1409
Still coding. Two effects down, "just" need music, effect sequencing, a logo, a better sidebar image and a start screen.

Doesn't help that my music player's in pieces on the floor at the moment; might be submitting in Samoa Standard Time at this rateĀ…
2015-12-28 09:05
Dane

Registered: May 2002
Posts: 423
PM if you need music, Christopher. :)
2015-12-28 14:45
Smasher

Registered: Feb 2003
Posts: 521
is that offer valid only for ChristopherJam, or?... :P
2015-12-28 15:46
Dane

Registered: May 2002
Posts: 423
Quote: is that offer valid only for ChristopherJam, or?... :P

That depends on if you need it for the Reu-compo. :)
2015-12-28 16:03
Smasher

Registered: Feb 2003
Posts: 521
sure, for REU compo 2016 or 2017... :)
2015-12-30 21:28
Shadow
Account closed

Registered: Apr 2002
Posts: 355
So deadline closing in fast - who will have a release and who will not? Exciting times! :)
2015-12-30 21:40
Dane

Registered: May 2002
Posts: 423
Go check you creustal ball and maybe it will tell you? :)
2015-12-31 20:10
Oswald

Registered: Apr 2002
Posts: 5095
treuly exciting times!
2016-01-01 11:06
ChristopherJam

Registered: Aug 2004
Posts: 1409
I just emailed Reutastic to the organisers a few minutes ago. It departed my machine at 11:59pm Western Samoan Time, a good hour before midnight on Howland Island. Hope that's ok!

edit - release is up
2016-01-02 13:32
lft

Registered: Jul 2007
Posts: 369
Happy Reu Year!

Allright, we got four excellent releases. Thanks to everybody who contributed!

Next up is the voting stage. We will note the average CSDb score for each entry, including anonymous votes, two weeks into the new year (in a timezone of our choice). So make sure to cast your vote before then!
2016-01-19 08:39
ChristopherJam

Registered: Aug 2004
Posts: 1409
Thanks for hosting, that was fun!

It's a shame the 1750 never really took off back in the day; it would have made such a difference.
2016-01-20 16:05
Bob

Registered: Nov 2002
Posts: 71
and I even used to own one :( hmm I wonder if Dragon has my REU ...
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
Mike
Matt
JCH/Vibrants
Fred/Channel 4
JEZ
REBEL 1/HF
grass/LETHARGY
Guests online: 130
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.6)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Sprite Bukkake 2  (9.6)
9 Uncensored  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.7)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 Morph  (9.5)
7 Dawnfall V1.1  (9.5)
8 Libertongo  (9.5)
9 Katzen-Video.mp4  (9.5)
10 Onscreen 5k  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Performers  (9.3)
4 Fairlight  (9.3)
5 Triad  (9.3)
Top Logo Graphicians
1 t0m3000  (10)
2 Sander  (9.8)
3 Mermaid  (9.5)
4 Shine  (9.4)
5 Pal  (9.4)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.139 sec.