Need your opinion regarding GR8NET capabilities

Master (232)

30-05-2017, 01:32

Eugeny,

If you want to do a better use of the slot x.3, you can use it like the Sanyo MSX2+ and add Basic-Kun there . In Sanyo MSX2+ machines the slot 3.3 have the MSX-Music in page 1 and BASIC-Kun in page 2. I guess this doesn't want any change in FPGA code, only in the ROM image.

Van DarkSchneider

Paragon (1030)

30-05-2017, 08:39

Eugeny_Brychkov wrote:

DarkSchneider wrote:

I.e. set it as MSX-Music, and would be like now, set it as MSX-Audio, and then the MSX-Music is hidden and the MSX-Audio would be raised to be at subslot 3, etc.

I can do it, I think there's still space for MSX-AUDIO ROM in flash chip, and it will require changes to FPGA configuration.
The only issue you should be aware of that you will not be able to switch ROMs "on the fly", reboot will be required.

DarkSchneider wrote:

But unless the device is made with a fully programmable implementation I suppose is not possible, if at some parts depends on pure hardware, because it would require a complete revision for the switching support.

FPGAs are powerful, that's why they are there!

If possible (I understand it takes your free time) please do it. That would be the ultimate device. I insist much on that because as developer I always program the MSX platform using the BIOS features (like originally was intended), so if I'd program for MSX-Audio I'd use its BIOS for device handling. And because this for me it is so important.

And because this, I'd like to ask for the other question: the BASIC extension are impressive, can all that be achieved with the direct firmware calls (AKA device BIOS)? I have not compared one-by-one but I'd like to know if the BASIC extension functions are a mix (one function calls multiple others to achieve its purpose) or there is some features that would lack on the direct BIOS side. So ASM/C/Pascal developers could access all the device power.

Van Robby

Master (219)

31-05-2017, 13:56

Eugeny_Brychkov wrote:

Robby wrote:

is the functionality CALLNETPLAYWAV in order to play mp3's expired?

There's nothing to expire. There's no term license

Robby wrote:

iBecause i receive a illegal function call.

There's magic command CALLNETCODE which may give you idea about the source of the issue.

Robby wrote:

However, i am able to play a mp3 file through call netbrowse, accessing my sdcard and pressing tab.

Please contact me by email or skype or FB chat, my first idea that there's something wrong with arguments.

Hi Eugeny, i've sent you a message by FB-chat

Van Grauw

Ascended (10821)

31-05-2017, 17:52

DarkSchneider wrote:

I insist much on that because as developer I always program the MSX platform using the BIOS features (like originally was intended), so if I'd program for MSX-Audio I'd use its BIOS for device handling. And because this for me it is so important.

You do know that if you do this, your software will not work with either the Philips Music Module or the Toshiba HX-MU900, right? Only the Panasonic FS-CA1 has the MSX-Audio BIOS built-in, and I can count the number of people who own one on one hand. I've only ever seen one myself once, a couple of years ago (after being an MSX user for many years), it's super rare.

Van Lord_Zett

Paladin (807)

31-05-2017, 18:00

yeah like if grauw dont see them the almost dont exist(really)

Van Manuel

Ascended (19679)

31-05-2017, 22:22

Grauw, there's a kit to build in the BIOS in the other cartridges (Created by FRS, was produced and distributed by SuperSoniqs a few years ago.)

Van Grauw

Ascended (10821)

01-06-2017, 12:46

I know the kit exists (have one myself for the sram upgrade, but not built in yet), so yes the brave souls who have modded their hardware also get to play it. But the goal of a BIOS is compatibility and that is the opposite you achieve here by sticking to a BIOS dogma (pardon the phrasing).

Van AxelStone

Prophet (3199)

01-06-2017, 10:48

Yeah but if you develop for a standar as MSX, not isolated system as CPC, Atari, etc, BIOS must be mandatory: it's the layer to ensure compatibility between models. Every manufacturer can assemble it's own FDD controller for example, but no mather wich hardware is behind if access comands are mapped in the BIOS. Even closed systems as CPC has a small BIOS since it's design can change along the years (Amstrad could assemble cheaper I/O controllers in sucessive models) and you need to ensure compatibility thorught different models.

It's known that a lot of 80's european MSX software has serious compatibility issues due to bad practices in development, basically, use direct access to hardware.

Van Grauw

Ascended (10821)

01-06-2017, 11:07

AxelStone: I’m referring to the MSX-AUDIO BIOS specifically, which is not universally present (rather it is quite universally absent).

Van Eugeny_Brychkov

Paragon (1232)

01-06-2017, 11:31

@all I would start asking if there's any programming API BIOS reference for the MSX-AUDIO.
(we do not take BASIC CALL statements into account).
In general MSX-AUDIO capabilities as a device are well documented, the only issue for programmer would be locating the ports chip is present in.