Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Tiger_HF ! (Registered 2017-05-24) You are not logged in 
CSDb User Forums


Forums > C64 Coding > Detecting REU + VICE
2009-01-08 01:29
AlexC

Registered: Jan 2008
Posts: 224
Detecting REU + VICE

I'm looking for reliable method of detecting REU on different machines (c64/128) and VICE. Either I'm doing something wrong or the only really stable method (without actually writing to REU banks like shown here: http://www.codebase64.org/doku.php?id=base:reu_detect) is this one:

lda #$00
sta $df00
cmp $df00
beq noreu

The following code fails on my C128D:
http://www.willcox.de/index2.htm

At this point I don't need the size of REU as I assume that every single one will provide me with 128KB at least and this is as much as I need.

Thanks in advance
2009-01-08 03:54
Groepaz

Registered: Dec 2001
Posts: 8017
lda #$00
sta $df00
cmp $df00
beq noreu


this is not stable at all... reading from open i/o (ie, no reu) will give you semi random values, so the above test will randomly produce wrong results.
2009-01-08 10:53
AlexC

Registered: Jan 2008
Posts: 224
Thank you Groepaz,

By "stable" I've meant that this is the only method that is not failing on my C128D - not that it would work in 100% - while other examples I've found based on REU register writing failed. I know that this is not the right solution. A simple BASIC loop can be used as an example:

fori=1to10:poke57088,0:?peek(57088):nexti

Any ideas how to detect REU presence in more reliable way? Or is writing to REU memory is the only way?
2009-01-08 11:08
Jetboy

Registered: Jul 2006
Posts: 177
Quote: Thank you Groepaz,

By "stable" I've meant that this is the only method that is not failing on my C128D - not that it would work in 100% - while other examples I've found based on REU register writing failed. I know that this is not the right solution. A simple BASIC loop can be used as an example:

fori=1to10:poke57088,0:?peek(57088):nexti

Any ideas how to detect REU presence in more reliable way? Or is writing to REU memory is the only way?


It is either working 100% or not working at all.
For reliable test you should try writing different values to different REU banks (mapped to the same address), then try reading those values and if they match with what you put there then REU is present (or other compatible device). Value you write should be different for each bank you test, to see if they overwrite.

----
http://colors.collectingsmiles.com
2009-01-08 11:56
enthusi

Registered: May 2004
Posts: 635
there can be only one reason to detect REU - so people dont have to chose/select manually.

PLEASE dont test by poking stuff into REU memory.
I seriously wonder why noone cares...
Among the few constant REU users (not me :)
many use it as ramdrive or to store code etc...
I wouldnt want a PRG to trash my data (secretly!).

It is VERY simple to circumvent this, yet noone does so.
Simply LOAD from REU into some c64-RAM before you try to write.
If write is successfull, restore the data previously fetched from that point.

Voila...
Sorry for smartassing but I dont like the general idea of detecting stuff by destroying it.
Reminds me of my famous CPU-meter: make sure CPU is 100%, then show that.
2009-01-08 14:13
Jetboy

Registered: Jul 2006
Posts: 177
Excuse me my ignorance, but does REU keep its content after power down? I always thought it does not. Never bothered to test it when i had it. It sucked bug time because i was not able to use it and AR at the same time. So the only real usage for me was copying disks in one run without need for additional shuffling. Once the copy session was over i was always disconnecting it to remount AR. When i got REU enabled TASM i was almost totally inactive.

----
http://colors.collectingsmiles.com
2009-01-08 14:43
enthusi

Registered: May 2004
Posts: 635
no, REU forgets mem.
However some might keep it plugged in for that very reason.
(there was some optional unit to power REU via batteries btw, (as for georam) but those were/are rare I'd say.)
2009-01-08 17:12
AlexC

Registered: Jan 2008
Posts: 224
Quote: Excuse me my ignorance, but does REU keep its content after power down? I always thought it does not. Never bothered to test it when i had it. It sucked bug time because i was not able to use it and AR at the same time. So the only real usage for me was copying disks in one run without need for additional shuffling. Once the copy session was over i was always disconnecting it to remount AR. When i got REU enabled TASM i was almost totally inactive.

----
http://colors.collectingsmiles.com


If you have port expander like DataLux you can use RR and REU together as RR is leaving $DF00 line free for exactly that reason. MMC Replay works only with very few machines and very few expanders so it's tricky but if you have RR you should be fine to use both at the same time.
2009-01-09 01:47
DemongerX

Registered: Jun 2002
Posts: 112
I've always been able to use my SSv5 with my 1764 ram expander, using one of the port expanders. I know some of them wouldn't allow concurrent use by different carts, but the one I use does. Been great for file copying use, especially 1581 disks in 1 pass.

DemongerX
2017-02-07 02:01
Bacchus

Registered: Jan 2002
Posts: 50
Bumping an old thread to seek advice. It's not like you concluded an example that seems to be agreeable.

Assumption: If the REU is in, $df00 should give a consistent value, but it doesn't necessarily have to be 0, does it? If there is no REU then $df00 could vary. If you read it once you could be be unlucky.

What about this? Read the $DF00 to get what is there (staic value from REU or random from unallocated mem). Then read it again 256 times and compare with the first read. If it fails one of the times it's likely so that $df00 is flickering ram and there is no REU. If it stays consistent over 256 reads, it's likely REU.

My Code:

start lda #00
sta $d020
sta $d021

tax
lda $df00
morecmp cmp $df00
bne noreu ;Assuming REU is not there
inx
bne morecmp

jmp reufound ;Assuming REU IS there

noreu
2017-02-07 02:03
Bacchus

Registered: Jan 2002
Posts: 50
I have to comment the codebase example:

reudetect lda #1
sta $0286 ; textcolor white
lda #00
sta $d020
sta $d021
sta banks
sta reubase
cmp reubase
beq noreu
bne unsafe
unsafe lda reubase

What did the guy drink? "bne unsafe", and then on the next line the label unsafe. I'm sure this is not done to produce that compensating extra cycle for stable rasters ...
2017-02-07 04:28
TWW

Registered: Jul 2009
Posts: 380
I really have no experience with programming REU but in my head, Commodore should have documented with the original REU units if there is a reliable way to detect them.

Further if this is not the case, I would probably write some data to the REU and then verify the same data is being fed back. Then repeat for N banks to determine the size of the REU.
2017-02-07 09:39
JackAsser

Registered: Jun 2002
Posts: 1215
What's wrong with n2c's suggestion?

1) Do a read from REU memory
2) Write some stuff to the address you read from
3) Read back the stuff
4) If they differ => no REU
5) If they do not differ => REU, restore memory corrupted using the backup from 1)
2017-02-07 10:33
AlexC

Registered: Jan 2008
Posts: 224
Somehow I can't belive that through all those years nobody came up with definitive solution for the problem. Agree with JA: what is wrong with this solution?
2017-02-07 20:33
Groepaz

Registered: Dec 2001
Posts: 8017
i'd do this:
- write $ff to some location
- set up DMA REU->C64 for a single byte, target on the choosen location
- trigger DMA
- check if still $ff, no -> REU present
(need to repeat incase the byte in reu was $ff)
- write $00 to that location
- trigger DMA
- check if still $00, no -> REU present
- else -> no REU present

or you could do what eg wheels does, i extracted the check once: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/REU.. (this also detects the amount of REU RAM, i think)
2017-02-07 23:13
Bamse

Registered: Apr 2013
Posts: 4
Just thinking:
Set up a dma for some bytes, no fixed address, execute with autoload off, then reload $df04 (or was it?). Increased value = REU present.
2017-02-07 23:24
lft

Registered: Jul 2007
Posts: 255
Another option is to run some non-destructive operation such as REU compare, and measure if there were lost cycles, and how many.

There's one thing I don't quite see, however. What is the point of detecting a REU if you aren't planning to use it? And when you use it, you'll trash whatever ramdisk was there. So why exactly do programs in general need non-destructive REU detection?

I think it makes more sense to warn the user that the REU is about to be used (whether it exists or not), and wait for a go-ahead. Also, REUs are often virtual these days, and this approach would provide an opportunity to enable the REU while the program is running.
2017-02-08 00:31
Groepaz

Registered: Dec 2001
Posts: 8017
or pop it into the c64! (rock'n'roll!)
2017-02-08 01:34
CRT

Registered: Oct 2012
Posts: 86
I read several clever methods here.

In Globe I just filled the REU registers and read them back, not my invention but does the trick.. "roughly". It does give a false positives with my EF3.

Could REU detection cause more serious trouble with other carts in the DF00 area? Like system freeze-up, etc. Poking wildly into an unknown device might not always be the best idea.
2017-02-08 09:35
Trash

Registered: Jan 2002
Posts: 86
I wrote some REU code a while ago and I tested for the reu by lda $d012, doing a compare of 256 bytes, sbc $d012 and comparing if the result was greater than 3...

But as CRT mentions, poking wildly into an unknown device could yield some unwanted results, you're better off just stating that a REU is required and have a manual confirmation or warn that you will be trashing the registers @df00...
2017-02-08 15:40
Groepaz

Registered: Dec 2001
Posts: 8017
crashes are expected when there is some cartridge - like FC3 :)
2017-02-08 18:46
Frantic

Registered: Mar 2003
Posts: 1301
Whatever nice solution you guys come up with in the end, don't hesitate to add it to codebase:

https://codebase64.org/doku.php?id=base:thirdparty#reu

:)
2017-03-18 14:01
Repose

Registered: Oct 2010
Posts: 129
There is a good reason to be careful. There's not just REU and it might be at different locations, with a port expander.

So I wrote the official test code for sid symphony, see if you can find that disk.

It carefully detects for REU, Snapshot, snd sid chip, at any location. I believe it also does size or maybe I didn't bother, but size is tricky because the size bit can be the same in two models, you have to actually write ram.

I often had two devices plugged in at once, so I need that.

Btw some tests will actually freeze your computer in one or other device, by mapping out your ram oops
2017-03-18 15:27
Groepaz

Registered: Dec 2001
Posts: 8017
"size is tricky because the size bit can be the same in two models"
there is no "size bit" in the first place - that bit tells you the state of the ram-type selection jumper. no more no less.
2017-03-18 16:12
Repose

Registered: Oct 2010
Posts: 129
I didn't know that, I just went by the manual. I had the smallest 1750, and never took it apart. Was there a jumper and it was user upgradable?

Still, that's reliable as it came in the box. If you change the jumper without changing the ram it's obviously your problem.
2017-03-18 16:28
Groepaz

Registered: Dec 2001
Posts: 8017
the jumper tells the REC chip what type of RAMs are used... so if you upgrade the REU you have to set it accordingly. iirc the two smallest REU types can use one type of RAMs, all the bigger ones use the other. (dont recall what is what)
2017-03-18 18:06
Repose

Registered: Oct 2010
Posts: 129
Ok I see, 64x1 DRAMS, and replace them with 16 256x1.

http://www.commodore.ca/manuals/funet/cbm/documents/projects/me..

The jumper J1 is same and cut with 1750 and 1764 (256 and 512k) but on with 1700 (128k).

So you can quickly guess 128k or 256k or more.
2017-03-19 10:45
oziphantom

Registered: Oct 2014
Posts: 122
10 PRINT "DO YOU HAVE AN REU PLUGGED IN OVER 128K? (Y/N):INPUT A$
20 IF A$="Y" SYS XXXX
30 PRINT "PLEASE INSTALL AN REU OVER 128K AND TRY AGAIN"
40 GOTO 40
2017-03-19 14:01
tlr

Registered: Sep 2003
Posts: 1118
40 GOTO 10

;)
2017-03-19 16:51
Frantic

Registered: Mar 2003
Posts: 1301
Hot Swap Gangsta
2017-05-17 21:17
Bacchus

Registered: Jan 2002
Posts: 50
Comments on a few of the aspects here;

=> My program assumes REU to work and it *will* trash the content. So you should never start it if you want to preserve the REU content. As rightfully asked by LFT, I have no reason what so ever to maintain it's content as it will be trashed anyway when the main code starts. Having a polite scanner that doesn't touch the content is hence sort of pointless IMHO.

=> CRT - I found this method;
http://psw.ca/robin/?page_id=182

He stores value in the registers and read them back. It's different from my store and read back 256 times, but it looks a lot like what you describes. Right?

=> My general concern is hence not to preserve REU but I also want to ensure that cartridges work. A working set-up is to have RetroReplay and REU and I want that to work.
2017-05-18 10:06
Trash

Registered: Jan 2002
Posts: 86
This is a piece of reu-checkcode I have used once upon a time. It isn't optimal in any way and trashes A + X registry and $df01, $df07 and $df08 but it works..


ChekREU  ;returns carry = 1 if REU is present
   sei
   lda $01
   sta store_01 + 1
   and #$30
   sta $01
   ldx #0
   stx $df08
   cpx $d012
   bne * - 3
   dex
   stx $df07
   ldx #%10010011
   stx $df01
store_01
   lda #$00
   sta $01
   lda $d012
   beq noREU
   cli
   sec
   rts
noREU
   cli
   clc
   rts
2017-05-20 10:45
Bacchus

Registered: Jan 2002
Posts: 50
Trash,

Thanx for the snippet. If I get it right you are setting up a compare, and such an operation takes time if the REU is there and no time if the REU isn't there, wherafter you use $D012 to validate if time passed. So the compare itself is not really relevant - it's the difference in duration you're after.

I buy that. It seems like a lot better way of doing it than trusting in memory at $dfxx being unstable where not REU is there.

Groepaz - how does that even work in VICE? Is there some sort of pseudo random return at reading the $dfxx addresses?
2017-05-20 11:18
Groepaz

Registered: Dec 2001
Posts: 8017
its not pseudo-random, it (open i/o) returns the last value that was on the bus, just like on the real thing :)
2017-05-20 11:57
Bacchus

Registered: Jan 2002
Posts: 50
Didn't work :-(

Tried it on Vice but $d012 was 04 regardless if I have enabled or disabled the REU in the settings. Tried it using the REU function in 1541 Ultimate II+ but same result...

// Check REU - based on Trash's code

sei
lda $01
sta store01
and #$30
sta $01

ldx #0
stx $df08
vicloop: cpx $d012
bne vicloop
dex
stx $df07
ldx #%10010011
stx $df01

breakhere: lda store01: #$37
sta $01
lda $d012
bne reufound

noreu: lda #<noreutxt
ldy #>noreutxt
jsr $ab1e
2017-05-20 12:20
Groepaz

Registered: Dec 2001
Posts: 8017
doh - that code can not work when the first thing you are doing is switching off the I/O =)
2017-05-21 20:58
Bacchus

Registered: Jan 2002
Posts: 50
Goepaz - it also doesn't work swapping in the I/O.
2017-05-21 22:23
Trash

Registered: Jan 2002
Posts: 86
I doesnt work because I am stupid and used old code that never worked. I found my detection routine that works without trashing to much stuff:

;-------------------------------------------------------
*= $0810
	sei
;-------------------------------------------------------
		ldx #0
		stx $df08
-		cpx $d012
		bne -
		dex
		stx $df07
; Exchange 255 bytes of c64 and reu memory
		ldx #%10010010
		stx $df01
; Exchange back
		stx $df01
; D012 == 0?
		lda $d012
		bne +
; Yepp, no REU
		lda #0
		sta $d020
		sta $d021
		cli
		jmp *
;-------------------------------------------------------
; No, REU
+	lda #1
	sta $d020
	sta $d021
	cli
	jmp *
;-------------------------------------------------------


The compare didnt work because it stop comparing at any difference.
2017-05-22 11:21
Bacchus

Registered: Jan 2002
Posts: 50
I ran Trash's core core in a continuous loop and then it reset the machine. Setting a source address seems to have fixed that.... Now it works for me!

sei

checkreu: ldx #$05
stx $df02 // Copy to $0500
ldx #0
stx $df03

stx $df08
vicomp: cpx $d012
bne vicomp
dex
stx $df07
// Exchange 255 bytes of c64 and reu memory
ldx #%10010010
stx $df01
// Exchange back
stx $df01

lda $d012
bne reufound
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
Groepaz/Hitmen
Alakran_64
oziphantom
Guests online: 56
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 The Shores of Reflec..  (9.6)
4 Coma Light 13  (9.6)
5 Lunatico  (9.6)
6 Comaland 100%  (9.6)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.5)
2 SidRok  (9.5)
3 Daah, Those Acid Pil..  (9.5)
4 Treu Love [reu]  (9.4)
5 Tunnel Vision  (9.3)
6 Dawnfall  (9.3)
7 One-Der  (9.2)
8 Hardware Accelerated..  (9.2)
9 Globe 2016 [reu]  (9.2)
10 Safe VSP  (9.1)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.4)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Camelot  (9.2)
Top NTSC-Fixers
1 Pudwerx  (9.8)
2 Horizon  (9.7)
3 Fungus  (9.6)
4 Booze  (9.5)
5 Stormbringer  (9.4)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 0.814 sec.