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.)
More awesomeness by openMSX - I will probably use this instead.
10 IF PEEK(&HF677) <> &HC8 THEN POKE &HF676,&H01:POKE &HF677,&HC8:POKE &HC800,0:RUN "AUTOEXEC.BAS"
Perfect... This should work great.
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).
Awesome, this is much simpler than I thought. I will definitely play with this.
Thanks so much!
I also made more progress on my graphic tool:
MSX2 Spriter (Github) with Pattern mode support!
Now you can make and export color-correct patterns as well. It will export an entire banks worth (768) of tiles and their colors to databytes. A few more feature additions and it might be worth making an exe for :)
Hello,
First, I've made quite a big of progress with my MSX2 graphics tools. I'll be making binaries of them soon since they're in pretty good shape. (I've expanded the functionality to create screen maps, and I'm almost done with a bitmap tool that supports all 4 bitmap modes and both vertical resolutions on the 'bitmap' branch).
Second, I'm having quite a bit of trouble playing music using the MoonBlaster drivers.
Here's where I'm at so far:
1. I made a crappy song in MB and saved it in USER mode. Using the BASIC driver, I can get the song to play in disk basic, so I know it's OK.
2. In order to get the song to play in assembly, I know the following to be true:
-The song must be loaded at $8000 (this is hopefully where it goes when calling MBLOAD)
-The SRCCHP routine must be called first - this swaps out bank 1 with MNROM when it's done, so I have to do my bankswitching after calling this
-STRMUS must be called to start the song
-The loader must be at org $d000
-The player must be at org $c000
3. Knowing the above, I do the following:
-Move all my workram variables out of the way (I moved them all to b000-b100)
-Assemble my game with the song at $8000 just in case, and start app code at $8300
-Copy the loader and player code, pre-assembled, into the correct target memory locations
-Call mbload (this doesn't seem to have any affect)
-Swap my bank
-Do all my other init stuff
-Call strmus (0xc017)
My game loads fine, everything is intact, I can run and jump around, but no sound plays. Poking the places in memory the player data is supposed to be shows the correct bytes, so it copied fine, but I'm just getting no output.
Has anyone else had this issue? Is it just easier to say screw it and work around using the BASIC driver?
I poked around the source but it's not commented and most of it is beyond me. Anyone have any suggestions?
No replies but I thought I would elaborate.
I tried assembly only driver using some VERY basic code in a standalone program:
fname "music.bin"
db $fe
dw $8000
dw EOF
dw init
org $8000
incbin "TEST2.MBM"
org $8300
init:
call loadtomem
call SRCCHP
call MBLOAD
;call MKLOAD
call strmus
loop:
jp loop
loadtomem:
ld de, $d000
ld hl, loader
ld bc, loaderend-loader
ldir
ld de, $c000
ld hl, player
ld bc, playerend-player
ldir
ret
player:
include "MBPLAY.SRC"
loader:
include "MBLOADER.SRC"
loaderend:
EOF:And I am getting the same results.
To that end, I've begun decrypting the BASIC driver and came up with the following info:
First, the call routines are loaded into 4000-4200, as in this list:
MBPLAY - 00 42 40
MBSTOP - 00 48 40
MBCONT - 00 4E 40
MBHALT - 00 54 40
MCHIP - 00 5A 40
MBANK - 00 81 40
MBADDR - 00 B2 40
MBFADE - 00 6B 40
MBALLOC -00 DF 40
MBVER 00 2F 41
MBMLOAD- 00 7E 41
MBKLOAD -00 06 42Second, it is loaded into RAM at b000h for whatever reason (as is apparent from the bin header) and extends to c62fh.
This explains why a) swapping out page 1 was breaking my game and b) why my workram (I moved from c000 to b000) was having issues.
Since the basic driver is the only one working for me at the moment I will continue to use it and hopefully work around its issues unless anyone has any ideas.