RIOT 6532 reading from the output pins..

[+rbairos]

I'm reading the original 6532 datasheet, and am curious what happens when you read a bit set as output.
From the documentation below is this correct?

Reading a PA bit set as output:  returns the direct external pin
Reading a PB bit set as output:  returns the stored output register value

Thanks,

Doc:

"Internal Peripheral Registers
The Peripheral A I/O port consists of eight lines which can be Individually programmed to act as either an Input or an output. A logic zero In a bit of the Data Direction Register (DORA) causes the corresponding line of the PA port to act as an Input. A logic one causes the corresponding PA line to act as an output. The voltage on any line programmed to be an output Is determined by the corresponding bit in the Output Register (ORA). Data Is read directly from the PA pins during any read operation. For any output pin, the data transferred Into the processor will be the same as that contained In the Output Register if the voltage on the pin Is allowed to go to 2.4v for a logic one. Note that for Input lines, the processor can write Into the corresponding bit of the Output Register. This will not affect the polarity on the pin until the corr'9sponding bit of DORA is set to a logiC one to allow the peripheral pin to act as an output. In addition to acting as a peripheral I/O line, the PA7line can be used as an edge-detecting input. In this mode, an active transition will set the internal interrupt flag (bit 6 of the Interrupt Flag register). Setting the interrupt flag will cause fRO output to go low If the PA71nterrupt has been enabled. The PA7line should be set up as an input for this mode. Control of the PA7 edge detecting mode is accomplished by writing to one of four addresses. In this operation, AO controls the polarity of the active transition and A1 acts to enable or disable interrupting of the processor. The data which is placed on the Data Bus during this operation is discarded and has no effect on the control of PA7. Setting of the PA7 interrupt flag will occur on an active transition even if the pin is being used as a normal input or as a peripheral control output. The flag will also be set by an active transition If interrupting from PA7 is disabled. The reset signal (RES) will disable the PA7 interrupt and will set the active transition to negative (high to low). During the system initialization routine, it is possible to set the interrupt flag by a negative transition. It may also be set by changing the polarity of the active Interrupt. It is therefore recommended that the interrupt flag be cleared before enabling Interrupting from PA7. Clearing of the PA7 Interrupt Flag occurs when the microprocessor reads the Interrupt Flag Register. The operation of the Peripheral B Input/Output port is exactly the same as the normal I/O operation of the Peripheral A port. The eight lines can each be programmed to act as either an input or as an output by placing a 0 or a 1 into the Data Direction register (DDRB). In the output mode, the voltage on a peripheral pin is controlled by the Output Register (ORB). The primary difference between the PA and the PB ports is in the operation of the output buffers which drive these pins. The buffers are push-pull devices which are capable or sourcing 3 ma at 1.5v. This allows these pins to directly drive transistor switches. To assure that the microprocessor will read proper data on a "Read PB" operation, sufficient logiC Is provided in the chip to allow the microprocessor to read the Output Register Instead of reading the peripheral pin as on the PA port."

 

[JetSetIlly]

These are the truth tables I have in the comments of the Gopher2600 implementation of the RIOT. According to the testing I have done, these are accurate.

 

Hope this helps.

 

For Port A:

 

SWCHA_W is what has been written into the register by the 6507 program previously

SWACNT is the DDR register

<input> is the signal coming from the peripheral

SWCHA is the value that will be read by the 6507 program

 

The truth table applies to each bit in the A register

 

SWCHA_W   SWACNT   <input>      SWCHA
   0        0         1           1            ^SWCHA_W & ^SWACNT & <input>
   0        0         0           0
   0        1         1           0
   0        1         0           0
   1        0         1           1            SWCHA_W & ^SWACNT & <input>
   1        0         0           0
   1        1         1           1            SWCHA_W & SWACNT & <input>
   1        1         0           0

 

And for Port B:

 

SWCHB_W   SWBCNT   <input>      SWCHB
   0        0         1           1            ^SWCHB_W & ^SWBCNT & <input>
   0        0         0           0
   0        1         1           0
   0        1         0           0
   1        0         1           1            SWCHB_W & ^SWBCNT & <input>
   1        0         0           0
   1        1         1           1            SWCHB_W & SWBCNT & <input>
   1        1         0           1            SWCHB_W & SWBCNT & ^<input>

 

The same as Port A except for the last entry.

 

I'm not entirely sure why the logic is slightly different for Port B.

 

 

edit: The test ROMs built by @Omegamatrix in this thread were helpful to me

 

 

Edited October 31, 2023 by JetSetIlly

[+rbairos]

That's perfect thanks.

[+SvOlli]

7 hours ago, JetSetIlly said:

I'm not entirely sure why the logic is slightly different for Port B.

I've got a theory that's just a guess, but sounds plausible.

 

I heard Chuck Peddle stating in an interview that the 6532 was a design (done by someone else) based upon the 6530. Since the 6530 needed way more address pins, the PB5, PB6 and PB7 were shared with CS1, CS2 and IRQ, respectively. So I think that there might be still some transistors left from the sharing of IRQ and PB7, that cause the different behaviour.

 

CS1 and CS2 however were mask programmable, so those might have a more indirect influence than the IRQ.

 

@JetSetIlly this also leads me to a question about your 6532 implementation. I've built a cheap computer by just throwing a 6502 and an RP2040 microcontroller (from a Raspberry Pi Pico clone) together. Could your 6532 emulation code work "standalone" in this environment running on the microcontroller? I'm still just considering options, I also want to take a look at Stella as well, but my guess is that it's very tightly integrated with the rest of the emulator. And yes, I know that I would need to port the code from Java to C.

 

[JetSetIlly]

9 hours ago, SvOlli said:

@JetSetIlly this also leads me to a question about your 6532 implementation. I've built a cheap computer by just throwing a 6502 and an RP2040 microcontroller (from a Raspberry Pi Pico clone) together. Could your 6532 emulation code work "standalone" in this environment running on the microcontroller? I'm still just considering options, I also want to take a look at Stella as well, but my guess is that it's very tightly integrated with the rest of the emulator. And yes, I know that I would need to port the code from Java to C.

I've not coded it with the intention of being separated from the rest of the emulator but it shouldn't be too hard to identify and extract the important logic.

 

Now that you've bought this up, I should probably document the RIOT package more thoroughly. The comments are fine but it could do with an actual design document. I don't have much time this week but I'll try to put something together, if only for my own satisfaction.

 

Gopher2600 is written in Go and not Java incidentally but that shouldn't present a problem for porting.

 

10 hours ago, SvOlli said:

I've got a theory that's just a guess, but sounds plausible.

 

I heard Chuck Peddle stating in an interview that the 6532 was a design (done by someone else) based upon the 6530. Since the 6530 needed way more address pins, the PB5, PB6 and PB7 were shared with CS1, CS2 and IRQ, respectively. So I think that there might be still some transistors left from the sharing of IRQ and PB7, that cause the different behaviour.

 

CS1 and CS2 however were mask programmable, so those might have a more indirect influence than the IRQ

That sounds plausible. Thanks. I would be interested in finding the interview where that Peddle says that.

[+SvOlli]

On 11/1/2023 at 10:32 AM, JetSetIlly said:

I would be interested in finding the interview where that Peddle says that.

Me too. I heard it during the time I was doing research for a talk about home computers from 1974 to 1977. So, those machines where a QWERTY keyboard was optional.

 

My best guess so far is the three part series with Bil Hurd, Jeri Ellsworth and Chuck Paddle.

Part 1:

Part 2:

Part 3:

 

Also taking a look at this page: http://retro.hansotten.nl/6502-sbc/6530-6532/tim-6530-004/6530-004-dissected/, it seems rather obvious. There are images which explain the functions of the areas on the die. The 1K bytes of ROM (plus mask for address decoding) is slightly larger than the 64 bytes of RAM. So should be easy to modify the design to drop the ROM in favour of doubling the RAM. And as far as I can tell, it looks like the 2600 design started out with a 6530 (the JOLT / TIM-1 system was used as the development kit) which was replaced later with the 6532.

 

Edit: interesting side-note: there is another difference between the 6530 and 6532. The function of A4 to turn on/off interrupts has changed. So you need an inverter at A4 to have the same address layout for I/O and timer functions. So that's what every KIM-1 clone utilizing 6532s does.