| Posted By
MIRKOSOFT
on 2015-02-16
05:56:03
|  Bankswitching of Plussy and its programming
Hi!
First time I want to try programming Plussy with bankswitching, but like I was learning C128 bankswitching many years ago, now I need to learn it in Plussy programming.
What serves bankswitching?
Is programming similar to C128 - storing value to MMU address and value representing MMU config?
If which values Plussy accepts.
Is extra provided MMU programming for detailed RAM usage like in C128?
I mean each bit represents part of RAM and its usage...?
C128 has also one bit as switcher of active CPU (8502 or Z80) - has Plussy any bit for CPU 7501/8501 config? Of course I know that not switch between CPUs...
Thank you for explaining me all.
Miro
|
|
Posted By
Litwr
on 2015-02-16
11:40:36
| Re: Bankswitching of Plussy and its programming
There are no RAM banks at base 64 KB C+4. RAM banks only appear with RAM expansions. C+4 has the ROM bank select ports ($fdd0-$ffdf) and the RAM/RAM toggle ($ff3e/$ff3f) ports. The ROM bank select ports set the current ROM configuration (for example, $fdd0 means standard Basic + Kernal ROMs) at $8000-$ffff address range, the RAM/ROM toggle ports set RAM ($ff3f) or ROM ($ff3e) for $8000-$ffff.
|
|
Posted By
MIRKOSOFT
on 2015-02-16
12:02:49
| Re: Bankswitching of Plussy and its programming
OK, not banks in base RAM...
So, I need to explain it:
e.g. C128 has 16 banks, each represents any ROM/RAM config...
Bank 0 represents RAM0 only, and top/bottom shared RAM is defined by MMU config.
Bank 1 represents RAM1 only, and shared the same - shared means visible no matter if RAM0 or RAM1 (RAM0 + RAM1 = 128K)
Bank 15 is special configuration with Kernal, Editor, Low Basic , High Basic etc.
Other banks refer to internal ROM expansion, external ROM expansiopn etc.
C128 uses also Banks working with RAM 2 and 3, but these banks referring to RAM0 and RAM1 - it's sometimes used for own made expansion to 256K...
I was thinking if Plussy can leave for Basic 60671 Bytes, there must to be anything similar 'cause C64 can also turn off ROM - but then are all Kernal and Basic routines unusable, so it's only disadvantage and C128 when needs makes active wanted RAM or wanted ROM - my meaning was Plussy must to be more advanced than C64...
So, Please explain it me like to little boy...
Miro
|
|
Posted By
SVS
on 2015-02-16
12:32:16
 | Re: Bankswitching of Plussy and its programming
Hi Miro,
summarizing, the Plus4 has 32K+32K of RAM and 32K of ROM online.
The RAM bank "hi" stands from $8000 to $FFFF, but the ROM too, as explained by Litwr. It is said "the RAM under the ROM".
If a program writes to a byte in that area, no problem: the value is stored in the RAM. On the contrary to read a byte there needs to set if you want read RAM or ROM (since the address is the same). The flag of TED map makes the work.
Not the whole RAM high bank is available for user. Some areas are always dedicated to ROM (I/O, TED, long jump routines, etc.). This is why Basic welcome string says 60K and not 64K free.
This is the operating way between ROM/RAM switching. If you are interested into RAM expansion operating (like 256K expansion) I can write you more.
|
|
Posted By
icbrkr
on 2015-02-17
20:26:43
| Re: Bankswitching of Plussy and its programming
Funny, I came here just to post this same topic.
I'm compiling a BASIC program that uses 40K or so of RAM (mostly as a buffer).
Obviously, as BASIC, it works fine. But when compiled, I run into the ceiling at 32768. I see you can 'turn off' ROM so you can read the RAM underneath, and I've also seen that you can stop interrupts for a sec and read what's underneath it. But how?
|
|
Posted By
SVS
on 2015-02-18
13:48:59
| Re: Bankswitching of Plussy and its programming
To turn off the ROM reading, just write into $FF3F location (any value, even zero). The following read operations (for ex. LDA) do read from RAM.
To return reading from ROM just write (any value) into $FF3E.
Of course if the nterrupt is active you have to avoid an IRQ call while the RAM reading is on. Since the IRQ routine resides into ROM it would cause a crash. Then when reading is set from RAM the interrupt has to be disabled.
Example:
SEI
STA $FF3F
.... reading operations from RAM
STA $FF3E
CLI
And now a question @icbrkr: what compiler are you using?
|
|
Posted By
icbrkr
on 2015-02-22
15:51:02
| Re: Bankswitching of Plussy and its programming
Wow... that's going to be a bit of a pain, since I'm reading ram constantly. Sigh. Good info, thanks.
Using Austrospeed (latest and greatest simple version).
So, now it gets a bit weird.
I've written a small routine to call from basic to pull back a memory location instead of peeking it. It looks like this:
* = $4ae8
LDA $3E8
STA $03
LDA $3e9
STA $04
SEI
lda #$00
STA $FF3F
LDY #$00
LDA ($03),Y
sta $3f1
lda #$00
STA $FF3E
CLI
RTS
Basically what I'm doing is adding the lowbyte/highbyte values of a memory location in decimal 1000,1000. Then I sys 19000 (location of the routine) to get the value back into memory location 1009. These locations reside in the tape buffer which I'm not using.
Inside the routine, it's storing the data at $03 because that's unused at this point (though I've done other values.. this is for the renumber feature of basic). Then I'm looking at the address it creates, and pulling data back and putting it at $3f1 (1009).
My program uses locations (decimal) 20000-whatever to store data. The program is using pointers to read through the data.
The above routine runs great until I hit around memory location $78d3. Then it coughs because the data is bogus. When I look at memory at this location, the data that is loaded from disk has been replaced with garbage. Since I'm not poking anything into this location, there's nothing being 'added', only read.
If I take the routine out and replace it with basic peeks, it works fine so I'm thinking it's this routine specifically but I don't see anything wrong?
To clarify, the data is loaded into that address, and before I run my program, the data is fine. When I break out of the program, the data is also fine. The routine is fine until I get to that memory address, and then if I break out, the data looks like it's been replaced by a mirror almost of lower memory.
|
|
Posted By
gerliczer
on 2015-02-22
17:56:49
| Re: Bankswitching of Plussy and its programming
Mysterious. Maybe you should try it without using the system reserved memory space by changing the zero page indirect indexed read into a simple absolute address read using self modifying code. Actually, the addresses $07f2-$07f5 can be used to set the CPU register values when calling a machine code subroutine with SYS, so there is no need to use the tape buffer for passing the requested memory address. And, according to the Ultimate Map, it also can be used to read the register values after exiting the routine, so you could omit completely the use of system reserved memory.
Now, some unrelated remarks. There is no need to write zero into $ff3e or $ff3f, because only the fact of write access counts not the written data content. There is no actual use of the zero value in the accumulator in your code, therefore you may omit this zeroing. The origin in your code example has a typo, it should be $4a38. The explanation too, because it refers to the 1000, 1000 addresses but the second should be 1001. These typos scared me a bit when reading your post, because I thought I misunderstood what you were trying to explain.
|
|
Posted By
icbrkr
on 2015-02-22
19:59:26
| Re: Bankswitching of Plussy and its programming
The org statement I threw in just for readability when I typed it up on here.. it's not like that in the original code.
I have about 3 or 4 ML programs stuffed into the cassette buffer (pretty common thing to do on the C64) since I'm not using the cassette drive at all. I can try moving the addresses somewhere else.
I know it doesn't need a value at $ff3f/3e, I was grasping at straws to find out what was wrong so I was trying some things.
I'm not sure what you're saying about 1000/1001. 3e8 is 1000, 3e9 is 1001. The low/high bytes of a memory address are being put in there.
I'm sure I'm doing something else stupid, but I'm not a huge ML coder at all.
What's interesting is that the ML programs both in the cassette buffer, and at 19000 decimal are fine after it starts doing weird things.
|
|
Posted By
gerliczer
on 2015-02-23
00:37:55
| Re: Bankswitching of Plussy and its programming
Well, then its time to thoroughly check what your other routines do. The corruption may come from them. As for the 1000/1001 thing, please read the first sentence of your explanation giving special attention to the numbers in it.
Using the tape buffer for running code also is a common practice on the 264 series machines. Probably it was inherited from C64 programming practice and experiences. Don't worry about being less than a superstar assembly programmer, I'm not one either. Once I was debugging my tragedy of code for hours when finally I realised that I mistyped an AND instruction instead of an ADD (or the other way around). Maybe you should try running your programme in an emulator that allows setting data breakpoints, if there is such an emulator for this machine. Or if your code is portable enough, try and run it in a C64 emulator with data breakpoint capability.
|
|
Posted By
SVS
on 2015-02-23
02:52:58
| Re: Bankswitching of Plussy and its programming
The problem of reading RAM under ROM was known by Plus4' OS creators. Hence they did put a special routine for that purpose.
Every time the Plus4 is turned on, the routine is copied onto $07D9...
Working info:
- Write on $7DF the zero-page address where is stored the RAM address of location to be read;
- .Y is used to index the reading (then set .Y=0 if no indexing is requested)
- JSR $07D9 and you'll have .A with the read value.
|
|
Posted By
icbrkr
on 2015-02-23
17:10:32
| Re: Bankswitching of Plussy and its programming
Well how about that. That looks a lot less convoluted.
Thanks everyone. I'll see if this doesn't resolve the problem.
| well
Okay.. I get it... from BASIC, I can give it the starting byte of the memory address
(as an example)
poke 3,255:poke 4,255. This gives me address $FFFF. Peeking that address, I know that it's 255.
So I poke 2015 ($7DF) with 3 to show that I'm looking at memory location $3 for the starting address.
I SYS to 2009 to run the routine.
The output of the accumulator is at $7F2. I peek that location from BASIC and I have my answer.
I tried it on a few random memory locations and it seems to work. Perfect, thanks.
|
|
Posted By
SVS
on 2015-02-24
08:06:01
| Re: Bankswitching of Plussy and its programming
Remember to set .Y=0 (POKE 2036,0) 
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
