How the FETCH S&X instruction really works ? - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: How the FETCH S&X instruction really works ? (/thread-45553.html) |
How the FETCH S&X instruction really works ? - Pavel Korensky - 10-30-2003 Hello, anyone knows, how the instruction FETCH S&X (hex 330) in HP-41 ? I know that this instruction fetch the word in system memory, at address specified in C[6:3] to C[2:0].
But what is the actual timing of this instruction ? During the next cycle 1, the HP outputs C (with address in C[6:3]). I suppose that the mechanism is similar to WRITE S&X (hex 040) instruction, which write to MLDL. But where and when is the peripheral unit supposed to put the word from system memory ? On ISA at the end of this cycle 1 ?
I tried to study all manuals and materials which I have, but I was not able to find any informations about this.
Re: How the FETCH S&X instruction really works ? - Monte Dalrymple - 10-30-2003 I haven't put an oscilloscope on this but I am pretty sure that this is how it works: It is a two word time instruction (obviously) that uses the second word time to access the ROM. The SYNC signal is suppressed during this second word time to prevent other devices on the bus from trying to decode the data (a 10-bit instruction) that is being fetched from ROM. The contents of C[6:3] are driven onto the ISA bus during the normal address time and the ROM returns the data at that location (again on the ISA bus) during the normal data time. At the end of this second cycle the fetched instruction is shifted into C[2:0]. I assume that the 10 bits are right-justified in C[2:0], but this assumption may or may not be correct. The timing should be such that the fetched instruction appears on the data line during the C[2:0] time.
HTH, Re: How the FETCH S&X instruction really works ? - Pavel Korensky - 10-30-2003 Are you sure about it ? Re: How the FETCH S&X instruction really works ? - Monte Dalrymple - 10-30-2003 Since the ROMs don't connect to the DATA line they can only transfer information over ISA... Remember that the Write S&X "instruction" is really just a NOP to the NUT CPU and it is only by convention that we say how external devices should interpret it.
Monte
Re: How the FETCH S&X instruction really works ? - Meindert Kuipers - 10-30-2003 FETCH S&X is not seen from the point of view of the ROM being addressed. All it sees is the 16-bit address on ISA, and all it has to do is return the 10-bit data on ISA, if that particular ROM is being addressed. This means that the ROM does not have to use the DATA line. Even the state of SYNC is more or less irrelevant for the ROM. The CPU will drive SYNC during reading of the 10-bit instruction if it is really an instruction to be executed. In all other cases, like FETCH S&X, but also the second word of an instruction in the GO and XQ, SYNC is not driven. This is important when implementing the WRITE S&X, since you have to be certain that your device sees the instruction only of it is being executed, not when it is for example part of a block of data or the second word of a GO or XQ.
Meindert
Re: How the FETCH S&X instruction really works ? - Pavel Korensky - 10-30-2003 OK, I understand. Re: How the FETCH S&X instruction really works ? - Monte Dalrymple - 10-30-2003 Not just "some unused address"! It needs to be in a page that is not already physically present. Otherwise you will have bus contention on ISA and perhaps blow either or both devices. Page 4 is used for the Service ROM or disabled IL printer, Page 6 is the Printer ROM and Page 7 is the IL Control Functions. I would use one of these pages...
Monte
Re: How the FETCH S&X instruction really works ? - Pavel Korensky - 10-30-2003 Yes, I meant some address from this area. The take-over space between 0x4000-0x4FFF seems like a good space. Re: How the FETCH S&X instruction really works ? - Meindert Kuipers - 10-31-2003 Pavel, You are almost right. Remember that you do not have to decode the $330 FETCH S&X instruction! The NUT processor does that for you. What your descriptor table needs to do is simply sit there and watch the address cycle on ISA, and return the data on ISA if there is a match in the address window. You suggestion to use page $4 is OK, just be careful not to use the lowest or highest addresses, otherwise the system might think that there is a service ROM connected.
Meindert
Re: How the FETCH S&X instruction really works ? - Pavel Korensky - 10-31-2003 Hello Meindert, I need to decode the 0x330 instruction by my hardware, because the descriptor table is not a part of the normal HP address space. Actually, it is not necessary to support descriptor read at all, but I want to have this feature for debugging purposes.
I will write you more by mail as soon as I will have my e-mail back. Currently, our mail server is packed in the box, because our company is moving.
Re: How the FETCH S&X instruction really works ? - Meindert Kuipers - 10-31-2003 Looking forward to your email. There is really no need to decode FETCH S&X. I have looked at this in detail, and I am implementing this in my MLDL2000. Just remap the addressing to your descriptor table and that should work. I was confused about this myself, but looked very closely at what exactly is happening. I use the Settings Registers to map a page in I/O space, and use that to remap to real-world I/O or access to FLASH and/or SRAM.
Meindert
Re: How the FETCH S&X instruction really works ? - Pavel Korensky - 10-31-2003 Hmmm, I tried to figure out how to do it without decoding FETCH S&X, but without success.
1. bits 12,13,14 of normal ISA address during normal ROM emulation or during cycle after ENBANKx instruction.
So, I implemented the FETCH S&X decoder and according to simulation (not yet complete), it seems that it works OK.
|