4

I am writing an emulator for the Jupiter ACE. I assumed the idle bus value would be 0xFF like the ZX Spectrum. Other emulators for the Jupiter ACE seem to assume the same. If there are no peripherals placing a value on the data bus what value should be simulated?

The reason I am asking is because I have come across a game for the Jupiter ACE, Valkyr, which is unusual in that it uses the Interrupt Mode 2. It places 0x3D in the I register but combined with a data bus value of 0xFF it fails, i.e. 0x3DFF seems to be the wrong vector and the simulated computer crashes back to the command prompt.

Improve this question
3
  • 2
    Are you certain the value is 0xFF always? Read this article about floating bus behaviour ramsoft.bbk.org.omegahg.com/floatingbus.html
    – knol
    Jul 8, 2021 at 13:09
  • There is a circuit diagram in TCJ issue 70. However with the way the video is done and all the resistors being used to avoid muxes between the video and the CPU when refreshing I'm at a loss to work out the value even with it. The ZX spectrum one is not always 0xFF either by the way. That's why games usually point I at 0x39xx as it's 257 bytes of 0xFF, then write 0x18 to 0xFFFF to get a JR backwards to FFF4.
    – Alan Cox
    Jul 8, 2021 at 17:34
  • 2
    Had a look in the ZesarUX source code for Jupiter ACE - That seems to assume $FF as well for the bus value in IM2. So, at least you're not alone ;)
    – tofro
    Jul 9, 2021 at 8:02

3 Answers 3

Reset to default
3

Thanks @kpalser - we simply followed your instructions and ran the code experiments to demonstrate that on multiple Jupiter Ace systems - originals not emulators or recent re-designs such as the Minstrel4th - the value is not FFh but 20h. I've connected the Ace to my scope and logic analyzer and one day have a rational explanation. Until then, it is what it is.

Incidentally, Looking at the Z80 I/O ports at address 2, 128 and 129 produces values which often vary with time, and keypresses.

Improve this answer
1
  • Thanks again for all your persistence in experimenting and finding other original ACE owners to participate. If the least significant bit of the port address is not set (i.e, all even address values like 2 & 128), then that makes sense because theory suggests the IN would read the keyboard. So the 129 being modified by the keypresses is a bit of an anomaly. I’m guessing something else is at play to remove the influence of the keyboard when the IM 2 vector read address is being created with the I register and bus value. If not Valkyr would potentially crash when keys are held down. Interesting!
    – Kpalser
    Jul 14, 2021 at 20:19
4

I found an article in the ACE User issues #4 from 83 that explicitly states the value to always be 0x20. enter image description here

Improve this answer
2
1

Looking at a schematic of the Juppi I think you can safely assume that a floating data bus is read as 0xFF.

There are several memory chips connected but none of them is active because /MREQ is not active during the interrupt acknowledge cycle.

And then there are the video RAM and the character RAM. In order to separate their data bus from the other memories, serial resistors are inserted. This way the video output can be maintained while the CPU accesses the other memories.

The data bus of the character RAM is directly connected to the pixel shift register. And here is the part that kind of pulls up the level. This shift register is a TTL chip 74LS166. The "LS" series has inputs that read "high" when left floated, see the Wikipedia page on "Transistor–transistor logic".

So each data bus pin of the CPU has a path to VCC, first the separating resistor of the Juppi of 1kOhm, then the emitter diode of the input transistor inside the 74LS166, and finally the base resistor of nominally 4kOhm inside the 74LS166.

EDIT:

This question circled in the back of my brain, and this answer is not complete. Unfortunately I don't have a real Ace to check, but this is what showed up.

  • If the video RAM is enabled to provide a character to the character RAM at the time the CPU expects the vector, the character will be read as such.
  • If the character RAM is enabled to provide a pattern to the shift register at the time the CPU expects the vector, the pattern will be read as such.

Hm... this might explain why 0x20 is read most of the time. It is the code for space. (Possible experiment: Fill the screen with any other character and see which value is read.)

Conclusion: There is no definite value. You cannot use IM2 reliably.

Improve this answer
3
  • Hmm it’s been verified as 0x20 on a couple of original Jupiter ACE computers: twitter.com/binarydinosaurs/status/1414291969107501062?s=21 plus my own experimentation with a game written for the original computer that fails with 0xFF. I haven’t answered my own question because I’m waiting for John Kennedy to post since he did all the leg work on getting an answer. Incidentally, clones like the Minstrel return a different value. Thanks for spending time to reply.
    – Kpalser
    Jul 13, 2021 at 17:46
  • Oh, interesting. If you (or any other) have some insight, please post an detailed answer. I'm especially interested why that value is read. Perhaps some charge from the former memory cycle?
    – the busybee
    Jul 13, 2021 at 19:12
  • If ever I get a definite answer, then I’ll be sure to let you know. Perhaps some one with a real ACE could follow up on your suggested test. One thing to bear in mind is that the Valkyr game expects the 0x20 value for the Interrupt mode 2 otherwise it will crash. And given that the Interrupt is being called 50 times a second, I’d be inclined to conclude that at least under the conditions it sets up that the value is reliable returned the same.
    – Kpalser
    Jul 14, 2021 at 20:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .