This is a cross-post from omnimaga, but:

So far, I have been able to produce tones over the IO port by toggling bit 4/5 of port B (7720 specs). Does anyone know how the Prizm's OS does it? I have tried the DAC hardware, but it isn't present, as well as the SIOF hardware, but wasn't responding. I can replicate what the prizm OS puts out from using Send(, but it doesn't seem right. I have been analyzing the output waves, but again, it looks like the OS has a tad more control. For example, writing to that port only outputs adds/subtracts voltage from the port. I don't know how best to explain, other than:
Code:


I could get in an image of my recording of it, but the above shows that it discharges inversely to 0 and writing to the ports doesn't set it, it just offsets it. When looking at the OS's IO output, it seems like it has analog control over it. It can keep the signal low or at an exact position, for ex.. If I am not making sense, :-S Fill me in on terminology

can you post an image of your analyzation? I'm not sure I totally follow you.

I sort of get it, but I too want to see some waveform diagrams or at least some programs I can test myself with an oscilloscope when I get some free time. Also, let me just leave this here:

http://www.cemetech.net/news.php?id=476

Unfortunately, that article doesn't mention the hardware, which is needed in order to output audio tones.

I will post an image of it later today when I record it on better hardware.

Quite so, because the previous investigations from the investigators with whom I had spoken had indicated that the individual line states that I would need to manipulate to produce tones were not available at all. As I said on IRC, I'm particularly learning if somewhere deep inside the chip the I/O lines are connected to a GPIO or UART/USART controller, and are in fact stuck being one input, one output or can be made bidirectional.

Well, so far, all of my recordings have shown that both channels having the same IO data, but that may b wrong. Currently, I am interfacing with Port B bits 4 and 5. Try making a program that simply writes there on and off and hook it up to an analyzer of some sort. One side effect: The calc must be turned off for the USB to be detected. Why? no idea.

Nope, try putting it in the main menu...

Hmm? No, the USB works? Have you written to port B? I only say that as I need to do that myself (1.02)

The Prizm can detect there is power coming through the USB when turned on: for example, just set the setting for Auto Connect (or whatever it is called, it's something "Auto") on the Link function, and a dialog will pop up whenever you connect the USB (and the calc is running Casio's code; it won't work on most custom add-ins, until you press the Menu key).

Indeed, but I think AHelper is saying that he sees a side effect where playing with Port B prevents the Prizm from auto-detecting a USB connection made while the device is on.

Exactly. Nothing gets detected - No backlight change, no dialog. I am not running a custom add-in when plugging in the USB, I am either in the main menu or in run-matrix mode and it fails to detect the USB. Maybe Port B fudges with the interrupts?

I grabbed SimonLothar's chm on the fx-cg10/20 and saw that there are notes about the registers. I will experiment later on.

USB works by adding/substracting voltage so port B 4/5 may control the USB and that's why the USB isn't recongized

hmm... I don't think that is how the usb works (other hardware controls the lines, not just add/subtract voltages manually) on the prizm, but it can be a raw access to the lines. My original theory was that that port was resetting the hardware based on how the io port worked when writing.

No, and I don't know of any controllers that like you messing with their lines directly. I honestly don't really care how it handles the lines. I'm more interested in everything above that. Anyway, I do believe it has something to do with the data bus. I'm still looking into it. Currently, I don't full understand the controller at all, but I'm working on it.

I'm pretty sure the USB not connecting thing has more to do with your interrupts. May I see your code, Ahelper?

I don't have any dedicated code for it. Just write 0b10000 to Port B, address 0xA4050140.

Heh, the USB controller on the z80 and m68k calcs let you mess with the lines directly and can be useful </sidenote>

Sorry, "like" doesn't actually equate to possibility. I know it's possible. It's possible on the sh3 too, I think. But there's not much reason to.

If you throw together some odd nonstandard USB hardware than it's possible and useful, but I'd prefer to connect something odd like that over the I/O port. Then again, the USB port does have that handy 5V supply...

Now I seriously wonder what happens to Vbus on the USB port when I write to port B... If it blips just like the IO port, it turns off, or the USB controller itself is changed somehow

More than six months have passed by, and it seems everyone forgot their Prizm has a USB port?

I'd really like to see some more discussion on the I/O hardware of the Prizm. IIRC, we already know that on the 3-pin port, there's one bidirectional line and one unidirectional line - this pretty much makes the Prizm incompatible with CALCnet, unless we can control both data lines of the USB port and then develop a custom adapter for it, in order to connect to a CALCnet hub or a CALCnet-enabled TI calculator... right?

For the IO: Well, we already know quite a bit about it. Music was already played back on it.

For the USB: That will be hard since the Prizm is peripheral-mode only. The ti8x calcs use USB OTG hardware, not the prizm. The OTG feature of the ti8x calcs makes them fun to play with since you can connect keyboards to it, or have it act as anything you want. The USB on the Prizm isn't known very well (directly, that is. I think there are syscalls documented for raw manipulation)