| |
AlexC
Registered: Jan 2008
Posts: 293 |
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
|
|
... 32 posts hidden. Click here to view all posts....
|
| |
Bamse
Registered: Apr 2013
Posts: 7 |
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. |
| |
lft
Registered: Jul 2007
Posts: 369 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
or pop it into the c64! (rock'n'roll!) |
| |
CRT
Registered: Oct 2012
Posts: 87 |
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. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
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... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
crashes are expected when there is some cartridge - like FC3 :) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
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
:) |
| |
Repose
Registered: Oct 2010
Posts: 222 |
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 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
"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. |
| |
Repose
Registered: Oct 2010
Posts: 222 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
