REU 16MB and using it

Started by MIRKOSOFT, July 27, 2010, 05:14 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

MIRKOSOFT

Hi!


I have emulated 16MB REU by 1541Ultimate.
All is pretty, but really don't know how to access it in BASIC:
I tried command STASH,2048,8192,49152,255
(store data 2048 bytes, from 8192 in RAM to 49152 in REU bank 255)
output: ?ILLEGAL QUANTITY ERROR...
Simple why: maximal value of BANK is 15...
This is the problem: when I can access only 16 banks, it's like 1024 kB REU, if I can use 256 banks, then it is 16384 kB (16MB) REU...


But this works not.
Is it really possible to access full size 16MB REU in BASIC?


Or I need to do commands FETCH/STASH only in assembler?
If in assembler, so, how?


It's first time when I'm using REU, can anybody explain it me and how to work with REU in assembler?
Many many thanks.


Miro
MIRKOSOFT of megabytes

Commodore 64 was great, Commodore 128 is bigger, better, faster and more!!!

http://www.mirkosoft.sk

hoss48458

A long time ago I messed around with this problem in vice and found this in the basichi rom (swap command)


monitor
    pc  sr ac xr yr sp
; fb000 00 00 00 00 f9
d faa53
. faa53  e0 10    cpx #$10
. faa55  b0 0e    bcs $aa65
. faa57  20 45 a8 jsr $a845
. faa5a  8e 06 df stx $df06
. faa5d  68       pla
. faa5e  a8       tay
. faa5f  ae d5 03 ldx $03d5
. faa62  4c 50 ff jmp $ff50
. faa65  4c 28 7d jmp $7d28

the above checks to see if the bank is bigger than 15 if so it prints an error message

using monitor command type f aa53 and you will see above in rom, the easy way of fixing this is to burn another rom and insert it with ea in aa53 such as below



monitor
    pc  sr ac xr yr sp
; fb000 00 00 00 00 f9
d faa53
. faa53  ea       nop
. faa54  ea       nop
. faa55  ea       nop
. faa56  ea       nop
. faa57  20 45 a8 jsr $a845
. faa5a  8e 06 df stx $df06
. faa5d  68       pla
. faa5e  a8       tay
. faa5f  ae d5 03 ldx $03d5
. faa62  4c 50 ff jmp $ff50
. faa65  4c 28 7d jmp $7d28


my solution was to just add ea`s (nop) ( no operation) to the 4 spots and it works fine, else you could write your own code and then jump to aa57

might be other ways of doing this but i found this the easy way out and it works

MIRKOSOFT

#2
I realized it by this code:



status   = $DF00    command  = $DF01    c128base  = $DF02    reubase  = $DF04
    translen = $DF07    irqmask  = $DF09    control  = $DF0A




lda #0
   sta control ; to make sure both addresses are counted up 
  lda #<$2000
   sta c128base 
  lda #>$2000
    sta c128base + 1
   lda #0
ldx#$c0
ldy #$ff   
sta reubase   
sta reubase + 1
   stx reubase + 2
sty reubase + 3
   lda #<$1000 
  sta translen
   lda #>$1000   
sta translen + 1   
lda #%10010000   
sta command   // execute

Miro
MIRKOSOFT of megabytes

Commodore 64 was great, Commodore 128 is bigger, better, faster and more!!!

http://www.mirkosoft.sk

LokalHorst

the above has a bug - you're using 4 reubase addresses (0 to 3) actually reubase + 3 is translen.
;)

MIRKOSOFT

yes, I did mistake when re-write code from ASM file, this is mistake only in this code in topic, not in real ASM file...
Miro
MIRKOSOFT of megabytes

Commodore 64 was great, Commodore 128 is bigger, better, faster and more!!!

http://www.mirkosoft.sk

XmikeX

Greetings,

I patched the REU filesystem for several REU configurations (under C128's CP/M), as noted here - http://www.commodore128.org/index.php?topic=3639.0

Much to my surprise, the original I/O code from 1985 seems to work flawlessly in VICE (it seems) all the way up to 16M, as illustrated in -- http://starbase.globalpc.net/~xmx/C128_CPM_REU_Patches-XmX.txt

;   Please Note: The REU I/O code in C-128 CP/M appears to be competent enough to parse through
;   the three-byte REU BASE ADDRESS ($DF04..$DF06) up to 16 Megs. Therefore, we will only focus
;   on modifying the DPBs while allowing the I/O code to perform as it normally does.

No data loss detected so far.  Original I/O code and new DPB's really seem to be in harmony (within certain limits as described in the link above).  The only visible hiccups right now come from analysis programs that presumably loop their 16-bit counters when reading the 16M filesystem i've patched in, as noted below:

http://starbase.globalpc.net/~xmx/C128_CPM_REU_Patches-XmXb.png

No worries.  The quick fix for a 16-bit counter issue is hopefully the obvious one : 65536 minus one :)

XmX