HP Forums

Full Version: How the FETCH S&X instruction really works ?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.


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 ?
Let's say that in cycle 0, the HP-41 fetch this instruction from ROM (address is on ISA and ROM send the 0x330 instruction at the end of cycle also on ISA).

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.

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.


Are you sure about it ?
The Write S&X instruction sends the address and data on DATA bus dirung second instruction cycle.

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.


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.


OK, I understand.
It means, that if I want to read back the content of the descriptor table in my CPLD (I am talking about the design of my ROMPack), I need to issue FETCH S&X from some unused address in HP-41 address space (somewhere between 0x0000-0x7FFF), interpret the 0x330 instruction and in next cycle, I need to output descriptor content on ISA. Right ?

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...


Yes, I meant some address from this area. The take-over space between 0x4000-0x4FFF seems like a good space.
I have 8 descriptors in the table, so 0x4F00-0x4F07 looks good for decoding.


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.


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.

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.


Hmmm, I tried to figure out how to do it without decoding FETCH S&X, but without success.
Problem is, that I need to multiplex three different sets of descriptor addresses as an address to descriptor table.

1. bits 12,13,14 of normal ISA address during normal ROM emulation or during cycle after ENBANKx instruction.
2. three bits from DATA latch
3. bits 0,1,2 of ISA address during second cycle of FETCH instruction. I am implementing the descriptor table read back as a fetch from addresses 0x4F00 - 0x4F07.

So, I implemented the FETCH S&X decoder and according to simulation (not yet complete), it seems that it works OK.