| |
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....
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
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: 225 |
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: 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. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
