Any idea on why moving HIMEM in slot 0 doesn't work?

Pagina 1/3
| 2 | 3

Door ducasp

Champion (315)

afbeelding van ducasp

21-06-2020, 00:08

Hi there,

I've been working on a ROM version of the UNAPI Driver of the SM-X WiFi adapter (so it works without RAMHELPR and also do not interfere with KANJI, CALL KANJI doesn't work when there is an UNAPI running with RAMHELPR, at least not with SM-X WiFi Driver or Obsonet and Internestor Lite), and just the 8 bits of slot work area are not enough, as I need to patch EXTBIOS as well as HTIM_I and also need a few more bytes (using 30 today) for internal needs of the driver.

This has been running absolutely fine on BlueMSX on any slot or sub slot 1 to 3 (yeah, I've made a Bluemsx version that emulates the SM-X IO driven UART and connect an ESP on a serial-usb converter and voila), but when you try it in slot 0, it either crashes on SM-X or doesn't recognize any Disk (be it a floppy interface, SCSI, IDE, SD, etc).

After a few tests, figured out that moving HIMEM in the cartridge initialization was the cause for it, if I do not change HIMEM when ROM first runs but only in the first UNAPI call, it works quite fine even in slot 0 (which is good, we have a free spot in SM-X / OCM in that slot and the rom goes nicely in there)...

While this works fine, I would like to understand why that happens? Is this an unwritten rule or is it documented anywhere? If I could somehow allocate the space at HIMEM at cartridge start-up, it would make the code a little bit leaner, as to do this work around, I need to access the slot work area at every UNAPI call to see if space in HIMEM has been reserved or not (as it is a rom and it doesn't have a single byte of ram, so to access work area there are a 20 or so instructions added at every UNAPI command call), it is not a simple ld a,(**) (unless I assume a fixed slot / sub slot position, I don't like this idea at all).

It is not that performance changes at all, it is working the same as the current RAM driver, but, seems quite a waste of cpu time... Tongue

Aangemeld of registreer om reacties te plaatsen

Van ducasp

Champion (315)

afbeelding van ducasp

22-06-2020, 15:24

Ok, gotcha... The problem is not the fact of sitting in slot 0...

It seems that disk roms, when setting up their work area, assume HIMEM is 0xF380, so if anyone set that lower before any disk rom is loaded, disk rom initialization would cause quite a mess when initializing static work area, so the device doesn't init at all...

https://www.msx.org/wiki/Disc_Communication_Area_(Disk-ROM_1.xx)

So, it seems that, in order to have your software to work along with disk adapters, no matter if they are initialized first thant the disk adapter or later, you have two options:

1 - Initialize your work area after boot
2 - Initialize like a disk and perform the initialization of disk hooks and initialization area and then place your work area below it, but then, if there are no disk adapters on that system, the workarea is useless memory that basic no longer uses

So, if your device is not going to create a disk for sure, it needs to have a work area in himem, and you want it to work no matter which slot it sits in regards to the any disk adapter, the only way to have its memory initialization is 1 :P

Van sdsnatcher73

Paladin (975)

afbeelding van sdsnatcher73

22-06-2020, 19:17

I’m no expert at MSX BIOS/BDOS but I was already pondering the following (mainly for Nextor). Here goes my theory: would it be possible that your ROM (or Nextor for that matter) search for BDOS on a machine (in all slots higher than where the ROM is) and if found call the initialization of that BDOS? I think some ROM games that support disk saving seem to do this but they obviously don’t give back control to the BIOS.

Advantages:
1. Your/other ROMS would have initialization of BDOS and as you wrote correct HIMEM.
2. Drive mapping for Nextor would be uniform on all MSX’s (on MSX’s with BDOS in slot 0 floppy drives are A: and B: and Nextor starts with and boots from C:, on others Nextor starts with A: and sometimes includes B: if there are multiple devices and floppy’s come after that as either B: or CSmile. Having floppy drives remain A: and B: makes live across several MSX’s more easy. Best would be if Nextor could boot from C: even if there was no BDOS.

Uncertainty for me is what happens if the BIOS calls BDOS again (after your ROM/Nextor has given control back to BIOS). Will it recognize it has already gone through initialization?

Van lintweaker

Champion (258)

afbeelding van lintweaker

22-06-2020, 20:05

I am not sure if this is what you are looking for, but there it goes. As far as I can remember there is a way for a ROM to 'wait' for the DiskROM to be initialized.

Van ducasp

Champion (315)

afbeelding van ducasp

22-06-2020, 20:24

It seems that hooking to hsteke is the way to go, it is called after all slots have been selected, so just add the real Rom initializer to hsteke chain, and initialize memory there. And then put my two hooks (extbio and htim) in the area allocated in high memory (currently one of the hooks is stored in the slot work area)

Van sdsnatcher73

Paladin (975)

afbeelding van sdsnatcher73

22-06-2020, 22:02

Sounds like a good plan also for Nextor imho!

Van ducasp

Champion (315)

afbeelding van ducasp

23-06-2020, 01:43

Not much luck, to execute basic Hook the function should be above 0x8000, UNAPI ROM starts at 0x4000 and in this case I can't use more than 16KB, so, those extra ten to twenty instructions do not look too much anymore Tongue Scanning for disk roms is not in my plan, so it suffice that it is working and the UNAPI performance is not any worse than the RAM Mapper Driver Tongue

Van ducasp

Champion (315)

afbeelding van ducasp

25-06-2020, 17:12

And here we are again... Issue, per say, is not much about H_STKE not allowing code in 4000, ESE SCSI is not booting if H_STKE is not empty, so, using H_STKE makes it incompatible with ESE SCSI... Weird design on their part to not allow this... Not going through this route as perhaps in the future this will be incorporated in an interface cartridge and wouldn't like to make it incompatible with ESE SCSI Tongue

Van Grauw

Ascended (9156)

afbeelding van Grauw

25-06-2020, 18:06

H.STKE is the normal way to boot until after DiskROM initialisation, officially documented and used in many software, such as any ROM game with disk support like Konami’s King’s Valley II. If ESE SCSI has an issue with it then it is a bug in their driver ROM and they should fix it because it will have trouble with many more software than yours alone.

Van zeilemaker54

Champion (278)

afbeelding van zeilemaker54

25-06-2020, 18:34

If you need to interact with other extensions which are using H.STKE as well, save the content of H.STKE somewhere, and install your own H.STKE handler. Your H.STKE handler should, after doing its own stuff, call the saved H.STKE.

Van sdsnatcher73

Paladin (975)

afbeelding van sdsnatcher73

25-06-2020, 19:06

zeilemaker54 wrote:

If you need to interact with other extensions which are using H.STKE as well, save the content of H.STKE somewhere, and install your own H.STKE handler. Your H.STKE handler should, after doing its own stuff, call the saved H.STKE.

Basically daisy chaining the handlers, makes sense.

Pagina 1/3
| 2 | 3