New dev using sjasm for MSX2, requesting aid :)

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

By shram86

Expert (88)

shram86's picture

30-04-2019, 21:21

Manuel wrote:

If you want .to load a piece of code in a place that normally isn't accessible in basic, like page 1, you could create a 16kB or whatever fits block which loads in page 2 and 3 with normal bload,r and at run time copies itself to the right place in ram. Then returns. You can repeat this for next blocks, if necessary. The last block starts the actual program in ram.

I've been trying to do this with no success.
I'm using the example in the technical doc to find the current slot, and swap in RAM page 1. Then I copy data into $4000, and reset the main-ROM to page 0 and 1, and return to BASIC - just as a test.

Everything seems to work except when I actually do the copy routine. Then the system freezes. Sad

By shram86

Expert (88)

shram86's picture

30-04-2019, 21:39

I think I'm running into a whole lot of SJASM bugs, combined with possibly bugs in Disk Manager.
The post-increment operators don't seem to work (like the code "?" flag from earlier).
Copy routine works now - but now, openMSX keeps telling me my autoexec.bas has a syntax error. This works as intended:

bload"palette.bin",r
(OK)
bload"game.bin",r
(game loads with palette @ $4000 as expected)

but this autoexec.bas fails now, every time:
1bload"palette.bin",r : bload"game.bin",r

I think I am doing this under the worst possible environment and keep hitting bugs that throw me off and think I'm doing things wrong which causes me to spend hours looking for a different way to do them.

By Manuel

Ascended (15763)

Manuel's picture

30-04-2019, 22:01

Try to list after you get the syntax error. Probably your basic program got corrupted by your machine language program.

By shram86

Expert (88)

shram86's picture

30-04-2019, 23:19

That might be what is happening, after a reset my LIST is indeed corrupt, but what about this:
I type
1bload"palette.bin",r
and I get Syntax error
but I type,
bload"palette.bin",r
and I get Ok.

I can write a listing right there in the BASIC prompt, run it and get the syntax error, list and it looks fine. If the autoexec is being corrupted that's one thing but for whatever reason I can't even run a single bload command within a listing without a syntax error. Am I hitting a dumb openMSX or linux bug?

Edit: If its not one thing it's another.
I said screw it and just used one bload command in my autoexec.bas and chained the load at the end of the first file with tokenized basic. Unfortunately, now I get Boot error when launching the system.

Though load"autoexec.bat" and then "run" works perfectly fine. Any ideas?

Edit 2:

Eeyup. It's an openMSX bug. Jesus, what a waste of a day Evil

By Grauw

Ascended (8457)

Grauw's picture

30-04-2019, 23:34

shram86 wrote:

Eeyup. It's an openMSX bug. Jesus, what a waste of a day Evil

What made you come to that conclusion? Because from what you described so far I find it unlikely to be an openMSX bug… Not because openMSX is bug-free or anything, but because those bugs are never in the Z80 execution and BIOS / Basic runtime environment, which is such a low level and battle-tested part of the emulator… not much that can go wrong there.

Did you test on a real machine? Did you configure openMSX to use the same machine? If openMSX is using a different machine configuration, you may have an interoperability problem, or may be using uninitialised memory, etc.

By shram86

Expert (88)

shram86's picture

01-05-2019, 00:02

Grauw wrote:
shram86 wrote:

Eeyup. It's an openMSX bug. Jesus, what a waste of a day Evil

What made you come to that conclusion? Because from what you described so far I find it unlikely to be an openMSX bug… Not because openMSX is bug-free or anything, but because those bugs are never in the Z80 execution and BIOS / Basic runtime environment, which is such a low level and battle-tested part of the emulator… not much that can go wrong there.

Did you test on a real machine? Did you configure openMSX to use the same machine? If openMSX is using a different machine configuration, you may have an interoperability problem, or may be using uninitialised memory, etc.

That's generally my last assumption, but I think it's approaching likely in this case because I'm using the linux build (most likely the least-tested version), using wine with Disk Manager (using wine with file editing is usually a bad idea), and using VS Code along with openMSX internally to edit my BAS files. All of this in conjunction is probably causing all of my autoexec woes.
1. Every so often I'll do a "files" command and it will have a corrupt listing.
2. Hard returns in autoexec.bas don't appear to be getting loaded in openMSX.
3. Inserting the disk after boot and using load"autoexec.bas",r works every time.
4. The disk auto starts fine in fmsx (not as reliable I know).

I don't have a flash cart to test the image with on my system yet (still in the mail) but if I get a "Boot error" then I'll revisit this, and see if it's possibly an issue with the HB-F1XDmk2. If worse comes to worse I'll just have to skip using autoexec.bas - it seems to be really unreliable anyway.

If you want to take a look at the disc image, here's a google drive link:
GDrive - inaz2.dsk
I'm definitely not knowledgeable enough to debug the BIOS - though it could be an issue with the BIOS image itself?

By Grauw

Ascended (8457)

Grauw's picture

01-05-2019, 01:11

shram86 wrote:

That's generally my last assumption, but I think it's approaching likely in this case because I'm using the linux build (most likely the least-tested version)

All the main openMSX developers are on Linux actually, so it should be very well supported.

shram86 wrote:

using wine with Disk Manager (using wine with file editing is usually a bad idea)
[...]
1. Every so often I'll do a "files" command and it will have a corrupt listing.
3. Inserting the disk after boot and using load"autoexec.bas",r works every time.

Have you tried the openMSX dir-as-disk feature? It can access a folder with your output files directly, there should be no need to involve a separate disk manager (if you doubt the latter’s robustness).

shram86 wrote:

and using VS Code along with openMSX internally to edit my BAS files. All of this in conjunction is probably causing all of my autoexec woes.
[...]
2. Hard returns in autoexec.bas don't appear to be getting loaded in openMSX.

MSX uses CRLF line endings, so on Linux you must make sure the editor saves them right. I myself have enabled the option to show CRLF line endings in my editor (Eclipse), so I can see immediately if they’re there.

shram86 wrote:

4. The disk auto starts fine in fmsx (not as reliable I know).

Between fMSX and openMSX, I sure as hell know which I would trust more Smile. Although also in fMSX I too would expect the Z80 / BIOS / BASIC to not have any issues, because it’s such a core aspect of emulation. But still openMSX is more representative because it accurately models many more machine configurations, and I suspect this may be where your problem lies.

The way you load seems somewhat suspect. From the A.BIN code you posted on the previous page, you seem to load it at 8000H. This will overwrite the currently executing BASIC program, which also starts at 8000H (unless you’ve relocated it with a certain poke, I forgot which). This explains the 1bload"palette.bin",r vs. bload"palette.bin",r issue to me (in the former after returning it continues to execute BASIC code that has been clobbered, causing an error).

Also this EXEBAS routine you call is not an officially documented entry point as far as I know (I’ve never heard of it at least), and I’m not sure whether it works on all MSX machines and generations. I wouldn’t use this, it’s commonly known as bad practice to make direct calls into the BIOS / BASIC system aside from the BIOS entry points and a few exceptions.

To load 32K of program data to 4000H-C000H I would take a slightly different approach; split the 32K into two 16K parts A.BIN and B.BIN like you did, and have each load at 8800H. In A.BIN, suffix it with code which selects RAM in page 1, copies the 16K to 4000H, selects BASIC ROM in page 1, and returns. In B.BIN, suffix it with code which copies the 16K to 8000H (using LDDR), selects RAM in page 1, and jumps to the entry point. Then BLOAD ,R both one after another in the AUTOEXEC.BAS.

(Or rather, I would find that poke to relocate the BASIC program to somewhere higher in memory like C800H, and load both parts to 8000H.)

shram86 wrote:

If worse comes to worse I'll just have to skip using autoexec.bas - it seems to be really unreliable anyway.

I much prefer either COM or ROM myself. COM offers a nice DOS environment with a large TPA space of RAM and easy to replace ISR. ROM offers quick and easy access to the BIOS and an endless amount of directly accessible ROM mapped memory. BIN has the advantages of neither and is more hassle, it mostly makes sense for hybrid BASIC / assembly or cassette programs imo.

shram86 wrote:

I'm definitely not knowledgeable enough to debug the BIOS - though it could be an issue with the BIOS image itself?

I presume you provided openMSX with this set of system roms in ~/.openMSX/share/systemroms/?

By shram86

Expert (88)

shram86's picture

01-05-2019, 01:15

Grauw wrote:

All the main openMSX developers are on Linux actually, so it should be very well supported.

Most enterprise devs are, too, but that doesn't stop Linux builds from being the least tested. Smile Good to know it's not the way I built it on my system though - I was extremely suspect of it to begin with when the only maintained distro was "opendingux" whatever that is.

Quote:

Have you tried the openMSX dir-as-disk feature? It can access a folder with your output files directly, there should be no need to involve a separate disk manager (if you doubt the latter’s robustness).

I hadn't - but I just did and it worked fine, so maybe its Disk Manager itself. I'd still like to be able to create my own .dsk images though - is there an alternative that works on Linux?

Quote:

MSX uses CRLF line endings, so on Linux you must make sure the editor saves them right. I myself have enabled the option to show CRLF line endings in my editor (Eclipse), so I can see immediately if they’re there.

Thanks for this tip - I was trying to find examples to compare with because I thought this might be the case but couldn't find any. Now I have an extension to display them and will be careful to do this from now on.

Quote:

The way you load seems somewhat suspect. From the A.BIN code you posted on the previous page, you seem to load it at 8000H. This will overwrite the currently executing BASIC program, which also starts at 8000H (unless you’ve relocated it with a certain poke, I forgot which). This explains the 1bload"palette.bin",r vs. bload"palette.bin",r issue to me (in the former after returning it continues to execute BASIC code that has been clobbered, causing an error).

This makes sense, and I thought that might be happening, that's why I switched it to the tokenized call.

Quote:

Also this EXEBAS routine you call is not an officially documented entry point as far as I know (I’ve never heard of it at least), and I’m not sure whether it works on all MSX machines and generations. I wouldn’t use this, it’s commonly known as bad practice to make direct calls into the BIOS / BASIC system aside from the BIOS entry points and a few exceptions.

I agree with you on this point but I was at a loss since I think my alternative is to learn the manual load-from-floppy assembly routines and use those instead (beyond me atm). My reference was this thread, which zPast says is the same for BASIC 1.0-4.1:
https://www.msx.org/forum/msx-talk/development/how-can-we-lo...

Quote:

To load 32K of program data to 4000H-C000H I would take a slightly different approach; split the 32K into two 16K parts A.BIN and B.BIN like you did, and have each load at 8800H. In A.BIN, suffix it with code which selects RAM in page 1, copies the 16K to 4000H, selects BASIC ROM in page 1, and returns. In B.BIN, suffix it with code which copies the 16K to 8000H (using LDDR), selects RAM in page 1, and jumps to the entry point. Then BLOAD ,R both one after another in the AUTOEXEC.BAS.
(Or rather, I would find that poke to relocate the BASIC program to somewhere higher in memory like C800H, and load both parts to 8000H.)

This is actually what I was trying to do, minus the 800h offset. I will revisit this. The relocate poke seems just as iffy as calling tokenized basic, though... Functionally, that does nothing but set the initial hex address where the program begins loading, yes? If so that might be an easier option.

Quote:

I much prefer either COM or ROM myself. COM offers a nice DOS environment with a large TPA space of RAM and easy to replace ISR. ROM offers quick and easy access to the BIOS and an endless amount of directly accessible ROM mapped memory. BIN has the advantages of neither and is more hassle, it mostly makes sense for hybrid BASIC / assembly programs imo.

I most definitely would use COM if I had any knowledge at all of it, or how to even boot into MSX-DOS. At the moment I'm at a loss without a DOS boot disk. I tried to replicate the behavior of games like Ys and Jikuu no Hanayome which have a JLOAD.COM file, but not only do the disks not load in Disk Manager but I've no idea how to compile a COM file.

Quote:

I presume you provided openMSX with this set of system roms in ~/.openMSX/share/systemroms/?

Yep, I'm using the same one.
Luckily, you've managed to diagnose it: combination of not using CRLF and Disk Manager being bad. :) Thanks!

By Manuel

Ascended (15763)

Manuel's picture

01-05-2019, 01:16

Also: autoexec.bas is very reliable. There isn't much that can be unreliable about it...

By Grauw

Ascended (8457)

Grauw's picture

01-05-2019, 02:00

shram86 wrote:

I hadn't - but I just did and it worked fine, so maybe its Disk Manager itself. I'd still like to be able to create my own .dsk images though - is there an alternative that works on Linux?

Probably there are better stand-alone alternatives on Linux (someone else should advice), however openMSX also has a built-in diskmanager tool which you can invoke on its command line or via a TCL script. (I use MacOS myself btw.)

shram86 wrote:

This is actually what I was trying to do, minus the 800h offset. I will revisit this. The relocate poke seems just as iffy as calling tokenized basic, though... Functionally, that does nothing but set the initial hex address where the program begins loading, yes? If so that might be an easier option.

Changing the BASIC program base address is used quite often, I’ve also used it in the past. Documentation from the MSX2 Technical Handbook:

MSX2 Technical Handbook wrote:

1. Change the starting address of BASIC text to 8021H.

POKE &HF676,&H21 : POKE &HF677,&H80 : POKE &H8020,0 : NEW

The NEW is needed to make it take effect, but you can also reload the program to achieve the same effect. Example first line to relocate AUTOEXEC.BAS to C800H:

10 IF PEEK(&HF677) <> &HC8 THEN POKE &HF676,&H01:POKE &HF677,&HC8:POKE &HC800,0:RUN "AUTOEXEC.BAS"
shram86 wrote:

I most definitely would use COM if I had any knowledge at all of it, or how to even boot into MSX-DOS. At the moment I'm at a loss without a DOS boot disk. I tried to replicate the behavior of games like Ys and Jikuu no Hanayome which have a JLOAD.COM file, but not only do the disks not load in Disk Manager but I've no idea how to compile a COM file.

Basically you just need the MSXDOS.SYS and COMMAND.COM files on a disk and it will boot to DOS. You can make an AUTOEXEC.BAT file to make it start a COM file automatically. The DOS2 programming environment is described here and here. In short: the program starts at 100H and needs no header. In DOS1 you can only use the function calls up to 40H. BIOS calls need to be done through interslot calls (get BIOS slot ID from 0FCC1H). Make sure to re-enable interrupts after interslot calls.

Example: Hello World (COM version) (also ROM and BIN version).

Not saying COM is better or worse than ROM btw. Both environments have their benefits.

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