RST 30h

Page 4/7
1 | 2 | 3 | | 5 | 6 | 7

By gdx

Prophet (3087)

gdx's picture

10-10-2018, 11:56

Grauw wrote:

Probably the mapper cartridges were also a consideration, but the one does not exclude the other.

I not exclude the other. I have the original book. This chapter just explains that the primaries slot 1 and 2 must each be a cartridge slot, slot 0 or 0-0 must contain the main ROM and slot 3-0 the Ram, then other internal Roms must be in remain expanded slots 0 (if expanded) or 3. There are two diagrams given as examples. Here are the scans:


It isn't related to RST 30. The goal is to simplify the search in the slots. Many MSX2 use a similar configuration of slots. Only the older ones have a very different.

By DarkSchneider

Paladin (880)

DarkSchneider's picture

10-10-2018, 13:10

Eugeny_Brychkov wrote:

@DarkSchneider, I alreaddy did it to prove that issue exists. Can you answer my questions above?

Well, the aswer is there. A programmer wants to call to slot 0 other than ROM to make use of all the 64KB of RAM. Seems to be machines with 64KB (MSX2) not supporting that.

By Eugeny_Brychkov

Paragon (1106)

Eugeny_Brychkov's picture

10-10-2018, 13:56

Looking at pictures posted by @gdx I would say having anything in CPU bank 0 in subslot of slot 0 (apart from main ROM) is simply NOT SUPPORTED by design, and we just have a proof of it through RST30.

Answer is not there for WHY programmer wants his stuff in subslot of slot 0. And if it is possible to change this requirement instead of writing additional slot changing code.

And answer is not there for HOW programmer gets something useful into subslot of slot 0 (onboard RAM? He has machine with cart connector for slot 0-1?)

Let's stop speculating on the generic issues, I prefer consider this specific case, and only then generalize if it is possible.

By DarkSchneider

Paladin (880)

DarkSchneider's picture

10-10-2018, 14:18

That is MSX2+, much time later than the original design.

"There" I mean my previous answer, not the @gdx one. If a programmer wants to use the 64KB, the page 0 must be accessed in any form, if not you are accessing only up to 48KB. So there is the WHY for programmer.
The programmer does no choose to put things on subslot 0, he wants to put them on RAM, then is the system design what determines where are placed.
The system then also brings with functions to handle that, but then on some systems they dont' work.
You don't target an specific RAM in any slot, you use what the system gives to you. Usually will be the internal RAM.

On a PLATFORM like the MSX is, instead a machine, there is no place for specific cases, only the generics.

By Eugeny_Brychkov

Paragon (1106)

Eugeny_Brychkov's picture

10-10-2018, 14:21

So let's return to one of my previous questions - what are the machines having RAM in slots 0-1, 0-2 or 0-3 in CPU bank 0?

By DarkSchneider

Paladin (880)

DarkSchneider's picture

10-10-2018, 14:26

There are some, in previous pages of this topic I think are mentioned. They are what I call "faulty systems", because IMO they are not complying with the specification.

If we see at the instructions like ENASLT or CALLF, they are not noted with the exception "don't use for page 0", and it's true for most systems, but for those. If really doing it to page 0 were not supported by the specification, then I think they would have noted it in the instructions. There are instructions with notes, so putting some more, no problem.

Then I think the original idea is that yes doing it to page 0 is supported.

In this case the responsability would be for the manufacturer, they have to test if their own systems work. If you put 64KB on a computer, and the page 0 cannot be accessed by the system functions...then put the RAM on another slot than 0 or modify the BIOS functions. But they have to work in the standard manner.

By Eugeny_Brychkov

Paragon (1106)

Eugeny_Brychkov's picture

10-10-2018, 14:51

I see, thank you. There're really two machines mentioned - Sony HB-F500 and Victor HC-95.
Both MRC wiki articles state the following:

Quote:

a configuration that can cause poorly written software to crash

In light of our current discussion it means that MSX-BIOS ROM is poorly written. I think I have already suggested to make this statement less harsh a little than this, but people decided that the tone of current is ok Smile

Then I have further question: if CALLF does not work properly on these machines (I must check though) how RAM in CPU bank 0 is being used - for example, by MSX-DOS? Both machines are MSX2, but should be capable running DOS properly.

By Grauw

Ascended (8515)

Grauw's picture

10-10-2018, 15:36

Eugeny_Brychkov wrote:

Looking at pictures posted by @gdx I would say having anything in CPU bank 0 in subslot of slot 0 (apart from main ROM) is simply NOT SUPPORTED by design, and we just have a proof of it through RST30.

I agree with that. The omission of this detail from the CALSLT / CALLF documentation does not mean that it is thus something that the BIOS supports (it clearly doesn’t as evidenced here). It’s also omitted from ENASLT, however there it already follows from logical reasoning that this isn’t possible, nobody complains about that Smile.

DarkSchneider wrote:

"There" I mean my previous answer, not the @gdx one. If a programmer wants to use the 64KB, the page 0 must be accessed in any form, if not you are accessing only up to 48KB. So there is the WHY for programmer.

In my opinion the answer here is that the programmer is supposed to use DOS. That was the prime purpose for 64K systems anyway, at least from a machine marketing perspective. In the BIOS environment, you’re not supposed to call methods in the RAM of page 0. You can still use it for data storage through RDSLT / WRSLT.

DarkSchneider wrote:

On a PLATFORM like the MSX is, instead a machine, there is no place for specific cases, only the generics.

And yet they are there, as part of our standard. Call it design flaws in the BIOS or the architecture of the subslot system if you will (especially the latter seems obviously convoluted Smile). If there is such a restriction in the BIOS, they should have declared in the standard that you’re not supposed to put anything in page 0 of the expanded slot 0. Yet they didn’t forbid it, so manufacturers did what is permitted and probably was logical to reduce component cost.

DarkSchneider wrote:

In this case the responsability would be for the manufacturer, they have to test if their own systems work. If you put 64KB on a computer, and the page 0 cannot be accessed by the system functions...

Using DOS to test, everything probably worked fine. Probably very few if any cassette or cartridge software actually even used more than 48K, so what were the manufacturers supposed to test with. You can’t place a burden on them to be aware of and test such intricate edge case details of the inner workings of the BIOS and its potential limitations if they receive no warning from ASCII.

DarkSchneider wrote:

They are what I call "faulty systems", because IMO they are not complying with the specification.

So I don’t think it’s right to put the blame on the manufacturers (and call them faulty machines). Where does it say that this slot layout they used is not permitted? I think if there’s anything to blame it’s imperfections in the standard. They admitted as much by addressing the issue in the MSX2+ revision of the standard.

The relevant difference between those two being that the former is being used in this thread as an excuse to lower compatibility. If you truly take compatibility at heart, it makes no difference about who’s to blame.

By Eugeny_Brychkov

Paragon (1106)

Eugeny_Brychkov's picture

10-10-2018, 15:35

Ok, confirmed that HB-F500 crahses, and DOS is running properly for simple reason - it has Disk-ROM in CPU bank 1, and does not operate PSSR at all when switching between RAM and main ROM (I did not investigate further, but suspect DOS knows that RAM and ROM are in the same slot).

Let's imagine application wants to call address 0x100 in slot 0-2. Calling code itself is located at 0x4100 in 0-2 (in RAM). And it uses ROM only (no DOS).

CALLF, as well as ENASLT and CALSLT commit suicide. Thus I am afraid the only way to fix it is to have own routines residing in CPU banks 1 or 2 - well, came to the same conclusion as @Grauw Smile

Grauw wrote:

or write our own custom slot switching routine to use for swapping out page 0 and putting that in another page (not recommended by me in general).

Why not? No need to invent bicycle, just copy the flow of the routines from the main ROM.

By Grauw

Ascended (8515)

Grauw's picture

10-10-2018, 15:50

Eugeny_Brychkov wrote:
Grauw wrote:

or write our own custom slot switching routine to use for swapping out page 0 and putting that in another page (not recommended by me in general).

Why not? No need to invent bicycle, just copy the flow of the routines from the main ROM.

Primarily because (sub)slot switching is a fairly complex system to get right in all cases, programmers tend to use shortcuts like not supporting subslots (many software) or only supporting subslots if they’re in a different slot of the code (SMW and also several others) or always assuming all slots are expanded to simplify the code (I made this mistake once and it unexpectedly corrupted mapper memory).

Basically I’ve seen too many people get this wrong and harm compatibility as a result. In my opinion someone should only undertake this if the author really cares about compatibility, is really careful with the implementation, and tests thoroughly on many systems and configurations with slotexpanders. And since the testing surface of possible configuration alone is so large, it’s pretty difficult to test it properly.

In my corrupted memory bug case, it only became apparent on a system with two mappers, with the primary mapper being in a subslot and the secondary in an unexpanded slot, and then the code happening to play a VGM that was big enough and crash on the corrupted byte at 0FFFFH of the first bank of that second mapper rather than just sending a wrong sound chip register value which would be easily missed.

Not sure if those routines can "just be copied from the main ROM", doubt it’s a simple separate block of code that can just to be copy/pasted, and then as programmers adjust it to work in page 1 they tend to get seduced to trying to optimise (and break) it anyway.

So I could explain all this, but my short recommendation is always: "don’t do it unless you must".

Page 4/7
1 | 2 | 3 | | 5 | 6 | 7