| |
AlexC
Registered: Jan 2008 Posts: 299 |
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.... |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
"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: 225 |
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. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
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) |
| |
Repose
Registered: Oct 2010 Posts: 225 |
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. |
| |
oziphantom
Registered: Oct 2014 Posts: 490 |
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 |
| |
tlr
Registered: Sep 2003 Posts: 1790 |
40 GOTO 10
;) |
| |
Frantic
Registered: Mar 2003 Posts: 1648 |
Hot Swap Gangsta |
| |
Bacchus
Registered: Jan 2002 Posts: 156 |
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. |
| |
Trash
Registered: Jan 2002 Posts: 122 |
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
|
| |
Bacchus
Registered: Jan 2002 Posts: 156 |
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? |
Previous - 1 | 2 | 3 | 4 | 5 - Next |