just a question:
if i had a 16k machine and i bsave a basic program how can be bload(ed) with a another machine with different memory size?
Even assuming that the basic program fit in memory, i see an issue with statements that have as argument a basic line number.
for example a line like GOTO 100 would mean, in terms of cpu to a physical memory address where to jump, how can be the same address with different machines and configurations? Does the BASIC keep target address in relative form?
On an MSX 16K, you must put DATPTR at C000h and TXTTAB at C001h instead of 8000h and 8001h in the asm program, and use my method to save the program by setting DATPTR to C000h and TXTTAB at C001h before if you save on an MSX of more than 16K.
for example a line like GOTO 100 would mean, in terms of cpu to a physical memory address where to jump, how can be the same address with different machines and configurations? Does the BASIC keep target address in relative form?
When program is entered to memory the line numbers in instructions like GOTO are stored as line numbers... They will change in to addresses only when the instruction is executed for the first time. It is true that the saved programs store the original addresses next to line numbers, but BASIC automatically fixes these issues during loading (see routines #4253 = line numbers -> pointers & #54F7 = pointers -> line numbers) Usually this happens without user need to know about it, but ie. if you try to store BASIC program in ROM, this becomes very important to know, because other ways stuff like GOTO or GOSUB may end up failing.
I don't see that gdx or pgimeno solution would take this in to account, so using these versions I think the TXTTAB should be always same during saving and loading.
As I mentioned, my version requires minimum 32K. The Python program could fix up addresses; I just wasn't bothered by that because a >=32K requirement is fine for me.
Once the program is saved in binary file, the line addresses are fixed so it is not possible to load it to another aera.
Once the program is saved in binary file, the line addresses are fixed so it is not possible to load it to another aera. If you want to do something MSX1 16K RAM compatible, must enter the following pokes before loading the BASIC program into RAM.
POKE&HF676,0: POKE&HF677,&HC0: POKE&HC000,0:NEW
I had not taken this case into account to simplify the explanations.
Particularly I don't enjoy to sound like this kind of asshole, but I must say my version has no such restrictions and what comes to the rest... the correct POKEs for 16k machine are:
POKE&HF676,1: POKE&HF677,&HC0: POKE&HC000,0:NEW
I tested except the Python program. Indeed NEWSTT can be used to execute a complet BASIC program without use RUN. It seems work fine. Good job Pgimeno !
Since you seem to know BASIC well, I take this opportunity to ask you for help. I can't solve the following problem. The return to Basic is done but the disk instructions become unusable.
https://www.msx.org/forum/msx-talk/development/back-to-the-basic-from-dos
I have very little time lately, so I can't take a look, but I have to say that I don't know so much about BASIC, I just traced 7E14h and I found out that it jumps to 4601h with HL pointing to BASIC.
@NYYRIKKI How does your version avoid the LDIR overwriting the stub itself? And yes, sure, your version doesn't have these restrictions, but I just don't mind them. Also since you're already using undocumented stuff, you could save the ld hl,RUN and the ":RUN" string and jump directly to 7E14h. It also has the problem that the stub remains in memory when the program starts running - but that's easy to solve by moving the INCBIN before BEGIN and changing the header accordingly.
@NYYRIKKI How does your version avoid the LDIR overwriting the stub itself? And yes, sure, your version doesn't have these restrictions, but I just don't mind them. Also since you're already using undocumented stuff, you could save the ld hl,RUN and the ":RUN" string and jump directly to 7E14h. It also has the problem that the stub remains in memory when the program starts running - but that's easy to solve by moving the INCBIN before BEGIN and changing the header accordingly.
As I said, it is a bit stupid example that only shows the theory. I would use packing anyway if I would put it to cassette and although this is just partial solution ie. ZX0 has this "delta" value that shows how much compressed data and uncompressed data can overlap. The best solution naturally depends of the BASIC program it self. The 7E14 idea sounds good.
Although undocumented stuff is generally big "No, no!" on MSX world, there is also other way of seeing it. If you consider that disk drive is optional part of MSX standard then you may also consider these entry addresses as part of MSX standard because changing these routines in future would break all disk drive interfaces and DOS2 & Nextor cartridges that use these routines as well. My brain says that these exact routines in these exact addresses are very essential part of MSX standard regardless if they are documented or not.
NYYRIKKI,
Everyone don't all have the same programming experience as you. You seem to regard us as extremists of the standard when this is not the case for me, the problem is different. From experience, I know that it is better to use documented routines so that our program works on as many machines as possible. Even if the routine you propose has been tested on most configurations, I prefer to favor routines recognized as standard. I do otherwise when there is no other alternative. I do otherwise when there is no other alternative or when I need more speed or memory space. About Nextor, this isn't the best example as it seems to struggle to run properly on a few configurations but that doesn't stop me from really enjoying this software.
For examples:
Few people read the byte at address 0006h to read the VDP status register (usually they only read address 0007h for all accesses). I know very well that it has no influence whatever the configuration but I prefer to do it when it does not harm the execution of the program. I make direct accesses when it is beneficial or indispensable.
I sometimes use the C register to know the slot of a ROM when necessary because I know that it is 100% reliable. I also use often the usual routine although the latter direct access to the A8h port.
About floppy disk drives, they are MSX standard as long as they meet the standard. Optional part or not is same. All floppy drives are not full standard.
