Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


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

Registered: Jan 2008
Posts: 225
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
 
... 28 posts hidden. Click here to view all posts....
 
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: 385
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: 1217
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: 225
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: 8042
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: 261
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: 8042
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...
Previous - 1 | 2 | 3 | 4 - Next
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
ptoing
Fix/[HF] + [ONS]
Toggle/Padua
oziphantom
Alakran_64
Guests online: 52
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.5)
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 Daah, Those Acid Pil..  (9.5)
3 Treu Love [reu]  (9.4)
4 Dawnfall  (9.3)
5 SidRok  (9.3)
6 Achtung 5 Years Mayd..  (9.3)
7 One-Der  (9.2)
8 Tunnel Vision  (9.2)
9 Globe 2016 [reu]  (9.1)
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 Arsenic  (9.3)
Top Musicians
1 Jeroen Tel  (9.7)
2 Rob Hubbard  (9.7)
3 LMan  (9.6)
4 Drax  (9.6)
5 Linus  (9.5)

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