divmmc control

Discuss game and other programming topics not specifically covered in another forum

Moderator: Programming Moderators

User avatar
sol_hsa
Posts: 273
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

divmmc control

Postby sol_hsa » Tue May 12, 2020 12:41 pm

Continuing with my stupid questions, let's say I make a .nex application and map out all the memory with mmc register writes. Then I realize I want to load files off the sd card.

Here's what I assume I need to do:
- Output 0x80 to DivMMC control 0xE3 to map in the divmmc rom (first two 8k blocks; first being rom, second being one of divmmc memory slots, which I don't care about at this time)
- Do rst 8 + .db opcode calls to do the loading operations
- Output 0x00 to 0xE3 to get rid of DivMMC

I'd do all of the above with interrupts disabled in order not to blow anything up. Am I on the right track?

User avatar
SevenFFF
Posts: 565
Joined: Mon Jun 05, 2017 5:30 pm
Location: USA

Re: divmmc control

Postby SevenFFF » Tue May 12, 2020 1:04 pm

The rst8 API calls are documented extensively here.

It’s not necessary to page in divMMC memory before calling. That’s done for you automatically during the calls.

https://gitlab.com/thesmog358/tbblue/-/ ... S_APIs.pdf
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: divmmc control

Postby Ped7g » Tue May 12, 2020 2:42 pm

1) switch off Layer2 extra read/write mapping in the low address region. (port $123B - if you are using the extra mapping feature)
2) map ROM to the region (MMU0 $50 = 255, MMU1 $51 = 255) - if you are in NEX code loaded by NEXLOAD in common way and you didn't remap the ROMs to some custom alternative, just doing [255, 255] mapping should be enough.
3) make sure you have stack pointing to some valid piece of memory (I think this is already described in the API mentioned by SevenFFF)
4) do `rst $8`

The basic esxdos-like services like open/read/write/close should (AFAIK) work under all common conditions, not depending too much on current state of the machine or content of upper 48kiB of RAM (as divMMC related vars/buffers are in the non-MMU memory).

Alcoholics Anonymous
Posts: 781
Joined: Mon May 29, 2017 7:00 pm

Re: divmmc control

Postby Alcoholics Anonymous » Wed May 13, 2020 6:34 am

On the Next, you do normally have to have the rom present in the bottom 16k as mentioned. The reason is the divmmc is operated with automap off so that the hardware does not do any automatic paging and the rst $08 call is actually intercepted by rom code that pages in divmmc memory for the disk io. This is different from how esxdos handles things as it operates with the divmmc in automap mode so that it's the hardware that changes the memory in the bottom 16k to divmmc and that means the rom doesn't actually have to be there for things to work (although it's only a Next that might have something else there so the point is maybe moot, and a note that the byte at address 0x08 probably has to be the same as rom byte there).

The other idea you have of doing it by explicitly paging in the esxdos rom should also work but it is not how people are doing it. When you call esxdos functions when the esxdos rom is not already present (ie when the rom is there) parameters documented as being in HL must be in IX instead as the esxdos rom contains some code using HL when it must switch the divmmc rom in. If you place the esxdos rom there or if the esxdos rom is already there (eg when a dot command runs) then parameters documented using HL must be in HL. The way people usually deal with this is to forget about it and put the parameter in both HL and IX before making an esxdos call.

Interrupts in im1 mode are fielded by the esxdos rom. In original esxdos, the interrupt routine just returns but in nextzxos there can be user drivers registered to run on interrupt. I don't think the basic isr is run and those user drivers are located in divmmc memory if there are any (but they could be using allocated ram too). From a nex, you wouldn't want that stuff to run so disabling interrupts or using im2 would be the best thing.


Who is online

Users browsing this forum: No registered users and 4 guests