(SOLVED) 41CL - DOUBLE HEPAX ACCESS and MMU CONFIG

[hth]

(08-24-2019 08:31 PM)Monte Dalrymple Wrote:  

(08-24-2019 05:06 PM)rprosperi Wrote:  If the HEPAX, Advantage and IR modules handled these special OpCodes in h/w, how are CL, V41, etc. able to reproduce that behavior, meaning how do you know exactly what to have the emulation layer do to emulate the module's h/w behavior?

Is it "simply" educated guessing (e.g. looking at disassembled code, then taking a stab), followed by lots of testing, then rinse and repeat until it works?

For the Advantage and IR modules the special opcode is an ENROM instruction. This is also one of the cases for Hepax. The operation of this opcode is understood at a macro level, but there has always been the question of whether the following instruction is fetched from the current bank or the next bank. It seems that even HP wasn't sure about this, always placing the same instruction in that location in both banks. I don't remember which way I did it in the NEWT, but it works because the code tolerates either way. Unfortunately I don't know of an easy way to determine which way the legacy hardware actually works, because it would require modifying the contents of the physical ROM to test.

According to the SDS-II manual (the HP MCODE development tools back in the days), the 1LG9 chip, which is the HP memory that supports bank switching, bank switching takes place immediately after executing the ENROMx instruction and it is possible to switch banks on the fly to continue execution at the next address in a different bank.

Then why are not banks switched on the fly by old ROMs you might wonder. I think the reason is not due to hardware limitations, but rather limitations in tools. My coming tools (in beta at the moment) has a linker that can deal with placement of banked fragments relative each other based on assembler directives, to allow for switching banks on the fly. I do not think there are similar support in SDS-II, making it quite a bit harder to do it, but probably not impossible.

There are a couple of things with this 1LG9 chip. It requires that the ENROMx instruction to be preceded by an instruction with the highest bit cleared. HP code uses a "GOTO $+1" instruction before any bank switch instruction to ensure this. Also bank switching only takes place in the 1LG9 chip where the ENROMx instruction is fetched from. Having multiple 1LG9 based modules plugged in means that only the one providing the ENROMx instruction will switch bank.

We no longer have the 1LG9 and no ability to program such chips. The current crop of memories (MLDL2000, NEWT and Clonix) support bank switching in a similar, but not identical way. The obvious difference is that these memories provide more pages and can handle multiple modules. To make it mimic 1LG9, MLDL2000 and NEWT defines bank switching to be page 8-9, A-B, C-D and E-F (with some special rules on the low pages). Essentially following the plug-in module addressing scheme. Clonix is different in this, in that it actually bank switch all pages and have no such grouping at all.

This might sound a bit alarming, but so far it has not posed any problems due to the way modules are written (similar to in the old days) and bank switching all address pages on the Clonix has not been a source of problems, as no low pages are bank switched (apart from IR printer and 41CX ROMs, but that works as they are handled outside Clonix).

At least Clonix will have a problem if we ever start to bank switch page 4 and make it some library or system extension page. This will require some reprogramming of its firmware. It may also cause some issues with MLDL2000 and NEWT, but I have not investigated that. But there is no problem at the moment.

It can also be worth looking at that 1LG9 only checks the ENROMx instruction if executed from within the chip. I think the other mentioned memories do the same. Old MLDLs however, read instructions on the bus and can react to the WROM (write to ROM) coming from other devices, i.e. a Zenrom. This way a Zenrom (or other module with write-to-ROM functions) can work together with a RAM only box. This can be studied in the original MLDL design in that old PPC journal. For a memory chip, it is probably a lot easier to just decode the instruction fetched internally rather than implement logics for reading instructions that appear on the bus (as on the MLDL).

(08-24-2019 08:31 PM)Monte Dalrymple Wrote:  The IR printer also uses the special Peripheral instructions, which are also NOPs as far as the CPU is concerned. This operation is also well understood as far as the CPU is concerned, but I have never been able to find any documentation on how the IR module interprets them. I started looking at the code some time ago, but there are at least a dozen different "instructions" used and it's probably going to be impossible to figure out what they do from just looking at the code.

I think the best way forward here would be to try and track down some engineer that worked on the code or the IR module hardware. Peter Platzer had in his possession an MLDL that seemed to have been used for developing the firmware for that IR module. If he has some records where he got it, it might be possible to trace it backwards? Otherwise there may be people that are known to have worked on it or close to it at the time?

I mean, I implemented some algorithm for a quite cool optimization around 1994. I recently found my sketchbook from the time with all background information and the design of it. Information may exist and may be found if one asks the right person at the right time... Just a thought.