PBI interface to raspberry pi or Arduino

[ivop]

IIRC Robin tried using interrupts first on the UNO cart, but that turned out to be too slow. In C at least. Once the ISR was running, it had already missed its window. Perhaps you could make it work if you resort to assembly.

[E474]

Hi,

 

   Just to answer my own question about PBI edge connector sourcing (and for anyone else interested), this looks like a good link for anyone looking for a flat cable connector: https://www.aliexpress.com/item/33056457025.html

 

 

[Faicuai]

2 hours ago, E474 said:

Hi,

 

   Just to answer my own question about PBI edge connector sourcing (and for anyone else interested), this looks like a good link for anyone looking for a flat cable connector: https://www.aliexpress.com/item/33056457025.html

 

 

Amazon has them... more expensive, and less Qty. but all 50-pins.. Also, MUCH faster shipment, if buying in the U.S.

 

If buying in above context, I would certainly prefer or recommend Amazon over Ali-anything.

Edited September 13, 2019 by Faicuai

[suspicious_milk]

https://www.hobbytronics.co.uk/raspberry-pi-serial-port

https://atarimax.com/ape/ape.htm#multitask

http://www.dosemu.org/stable/

 

... just say'in

[ChildOfCv]

On 9/9/2019 at 10:21 PM, Xuel said:

With an Rpi, you'd probably have to write a bare-metal OS which polls the GPIO pins in a tight loop if you want a full-speed interface. Arduino is already pretty much bare-metal so might be a little easier. Another limitation with both Rpi and Arduino is insufficient GPIO pins.

Depends on which Arduino.  Remember that the Uno is not the only one.  The 2560 has nearly 70 pins that can be used as GPIO.

 

But that still leaves the issue of doing anything useful within the given time window.  Atmel chips take 5 clock cycles to respond to an interrupt, several clock cycles to see input changes from its I/O inputs, a couple to actualize output changes, etc, so even at 16MHz you can find yourself running low on cycles.  Also remember that it has 8-bit registers, so even accessing 16-bit memory sizes can take multiple instructions.  It's actually amazing how much more power an incompatible microprocessor-based solution has to have than the hardware that it's interfacing to, if it expects to run at the same bus speeds.  Of course, glue logic has the potential to drastically reduce those requirements, depending on the end goal.

 

[+Spaced Cowboy]

Yep.

 

I ran the numbers on using an Arm microprocessor when doing my Parallel port expansion project as well, and given the interrupt latencies, the bus requirement to respond with /MPD and/or /EXTSEL within 48 nanoseconds of getting a valid address is a pretty hard requirement.

 

50ns is a 20MHz clock, it's all ok to do it via hardware in the old days because you didn't need the flexibility of programmable memory apertures or what have you. It's a bit different trying to do that in a software world...

 

In the end I went with an FPGA. That way I could get very fast responses, and also have direct access to memory, giving me interesting opportunities for memory management

 

I'm still (slowly) working on it, even though the project thread went radio-silent. I think the cost was a problem (and I think I've found a way around that, roughly halving the cost at Q50) and I've got a board out with Seeed now to test out some of the connectors.

 

Anyway, just poking my head in - and letting people know I'm still playing/thinking about the PBXL, even though it might not seem that way

 

 

 

 

[E474]

Hi,

 

   Just speculating if you could do something along the lines of a UNO cart type solution where:

 

   ARM chip starts in polling mode, serves up 16K of 6502 code on 8-bit bootup that copies 16K of cartridge code to 8K - 24K lower memory address range (or similar).

 

   ARM chip goes in to/is put into buffer transfer mode, only operation it supports is returning 4K of video memory to 6502, but this is done by reading the same location in cartridge address space 4K times, to simplify address decoding.

 

   6502 reads 4K of screen memory from same address in cartridge address space, but writes it to sequental screen memory in lower RAM.

 

    After transfer of 4K, ARM chip has rest of display cycle to generate next 4K screen.

 

    Don't set up Antic to read from cartridge address space, so only data ARM chip has to send is when 6502 is doing buffer transfers.

 

   ARM chip can respond to interrupts from ports used to indicate it should go back into polling mode, or initiate another bulk transfer.

 

   I think the approach could be summed up as leave the cartridge address space alone unless you want to do bulk transfer of data, and if you are not doing bulk transfer, you can do other things with the ARM chip.

[E474]

6502 code would be something like:

SCREEN_DISPLAY_BUFFER1 = $6000

UPDATE_DISPLAY_BUFFER1
   LDA #>SCREEN_DISPLAY_BUFFER1
   STA DEST_ADDRESS + 2
   LDX #$10
LOOP1
   LDY #0
LOOP2
   LDA $A400 ; 1 byte interface into ARM generated 4K of screen memory

DEST_ADDRESS
   STA SCREEN_DISPLAY_BUFFER1,Y
   INY
   BNE LOOP2
   INC DEST_ADDRESS + 2
   DEX
   BNE LOOP1
   RTS
   
   

I think reading from the same address would also make it slightly faster, as opposed to reading from a base address, indexed by Y.

 

Once this code has been performed, ARM chip would be free until data for the next frame is required, which could go into SCREEN_DISPLAY_BUFFER2, for example, and could be a different 4K buffer in the ARM address space, and read from $A401, if you see what I mean?

 

Also, size of screen memory could be an arbitrary value, 4K is just an example value. Screen memory gets interpreted by ANTIC.

[E474]

Hi,

 

   Quick question, if the above code was executed 60 times per second, e.g. 60fps, how many cycles would the LOOP2 ... BNE LOOP2 code take (assuming the rest of the code only gets executed a few times) if there were 4096 loops, and how many cycles are available (I would guestimate 1.79MHz / 60 = 29933 cycles total, less any stolen by ANTIC). Not sure the screen would have to be updated 60 fps, though, to still be reasonably smooth.

[ivop]

3 hours ago, E474 said:

Hi,

 

   Quick question, if the above code was executed 60 times per second, e.g. 60fps, how many cycles would the LOOP2 ... BNE LOOP2 code take (assuming the rest of the code only gets executed a few times) if there were 4096 loops, and how many cycles are available (I would guestimate 1.79MHz / 60 = 29933 cycles total, less any stolen by ANTIC). Not sure the screen would have to be updated 60 fps, though, to still be reasonably smooth.

http://ivop.free.fr/atari/opcodes.html

 

You click the columns to sort...

 

and count yourself

 

4 + 4 + 2 + 3 (assuming branch is to the same page) = 13 cycles per loop

 

 

[E474]

Hi, 

 

   That's too many cycles!

 

   How about the ARM chip creating:

 

   LDA #Value,

   STA screen_location

 

Repeated 256 times to write a page of ARM screen memory to lower memory.

 

If you want to transfer 4K of generated screen memory into lower memory in the Atari, and, for example, this frame of data starts with $F3, $D3, $A0, then the ARM CPU creates instructions from, say, $A400 onwards:

 

UPDATE_DISPLAY_BUFFER1

   LDA #$F3

   STA $6000

   LDA #D3

   STA $6001

   LDA #$A0

   STA $6002

 

Then that is 2 + 3 cycles per byte. After you've moved 256 bytes, you can either JMP back to the start of the unrolled code, UPDATE_DISPLAY_BUFFER1, or serve up an RTS if you've returned all the data. 

 

For 4096 bytes, I get 5*4096=20480 cycles for transferring the buffer.

 

Then the ARM chip is free to generate the next frame data. That's if you are generating 4k of screen data, 60 frames per second, but I seem to remember there is something about only displaying data every other frame, so only 30 fps I/O?

 

   Ideally generating/transferring 8K / frame would cover Antic modes $F, I think, but I am not sure about the cycles I would have available.

[Sugarland]

I'm not a hardware guy (yet?) but it seems to me that a PBI interface board is needed to mate A8 to pi and/or Arduino. If it costs $60 that's doable and very desirable. It could also generate interest in A8 from the pi/Arduino communities.
 

On 9/12/2019 at 1:00 PM, Stephen said:

Not to poo-poo on any ideas, but one thing that always strikes me as funny about these threads.  We've had VBXE for over a decade now, and there's maybe 3 pieces of software that use it.  Many people feel it is "not atari" at that point.  We have Veronika and there's one piece of software for it (phaeron's BASIC).  It just seems odd to me that with so many unsupported mods out there, people keep trying to come up with more mods, but nobody seems willing to use what is out there.

 

Because VBXE does not connect via PBI/ECI?  Because VBXE is adding set-in-stone capabilities while an ARM PBI/ECI expansion would supplement the existing system with a far more flexible software-driven environment that is widely available and affordable? I don't understand the VBXE comparison except in a very general sense that they are significant upgrades.  I don't see this sort of PBI device as adding sprites or new graphics modes like VBXE but supplementing the system more like a MIO 2020 edition.

 

[ivop]

Why don't you want ANTIC read its screen memory directly from the cartridge address space? That eliminates the whole trasfer of data all together.

 

[E474]

Hi,

 

  I'm getting caught up in exploiting the capabilities of the ARM chip on the UNO Cart, as they have already been built, so am getting side tracked a little, but am enjoying it too.

 

  I started this thread as I thought a low cost 8-bit <-> Pi/Arduino bridge might appeal to hobbyists, and that RPi and Arduinos were commodity items.

 

  I have a feeling that the best way to use the ARM chips is to expect them to only respond to the address/data bus when it suits them. So the 6502 should not to jump in to the cartridge address space all the time, but test to see if there is (signature) data returned from the cartridge address space, then jump into the address space.

 

   Also, the ARM could generate 6502 code that reada the hardware on the Atari, so for example, if I move my game code onto the ARM chip, and want to read the joystick ports, keyboard scan code, etc., the ARM chip can generate code like:

	* = $A200 ; cartridge address space - code generated by ARM CPU on the fly

	LDA $D300	; PORTA
	STA $A200   ; address in the cartridge address space
	LDA $12     ; REAL TIME CLOCK
	STA $A201
	LDA $13 
	STA $A202
	LDA $14
	STA $A203

    JSR UPDATE_DISPLAY_BUFFER1
    RTS

    ; leave the ARM CPU alone (stay out of cartridge address space for the rest of the frame)

  

[E474]

Hi,

 

   Antic will read screen memory over the whole display cycle, so the ARM chip has to serve data all the time (e.g. it will always be polling the GPIO pins). If the ARM chip only has to serve data for the first 20 - 30 % of the frame, the rest of the time it doesn't have to be polling the GPIO pins, so can be used for creating the next frame's graphic data.

 

   Actually, I think it goes like:

 

   ARM chip creates screen data at 100 MIPS

   6502 reads screen data from cartridge address space to screen buffer RAM lower down in memory (once data transferred, ARM CPU now free to calculate next screen data)

   ANTIC displays contents of screen buffer in lower memory

 

   If you can say the ARM CPU has a clear 40% of the display cycle when it doesn't have to poll the GPIO pins, you have 40% of a 100 MIPS CPU at your disposal, e.g. a 40 MIPS chip.

 

[Kyle22]

Doesn't the ARM have time to do things on the same duty cycle as the main 65xx CPU? I mean can it do other things in that time? Our CPU's do it quite well.

 

[Kyle22]

If this could stream video from the PBI device or cart to ANTIC during DMA, then Dragon's Lair would be easy. All the videos from the original disc on the device's storage, and the game logic running on the Atari.

There would need to be a good communication channel between the two for best performance.

Great idea for a card for Incognito or proposed 890 expansion box.

 

:)

 

[E474]

Hi,

 

   If you don't know when the ARM chip has to supply data, you have to monitor the GPIO pins all the time by polling the ports in a loop, which ties up the ARM CPU. If you only transfer data as a single buffer transfer once per display frame, then when you have done that you can stop polling the GPIO pins, and get the ARM chip to do something else for the rest of the frame. Providing you finish that other work before the next frame's data is required, you're OK. Your still OK if you want to read data from the cartridge address space, you just want to indicate that the ARM chip is back into polling mode by returning a signature from a specific area in the cartridge like a string saying "Ready to transfer next block of data".

 

[ChildOfCv]

Are you talking about turning the ARM chip into a DMA controller?  An FPGA would be far better suited to such a task, as it can do the operations at the logic level instead of emulating logic with a series of instructions.

 

BTW, FPGAs are also reaching commodity level in the electronics community too.  I think I remember seeing that even Atmel makes at least one model of FPGA.

 

If you could cleverly allow the chip to access Atari memory during specific cycles (an Atmel 2560 has the ability to set up some of its pins for direct memory interface, but its memory access protocol might not be reconcilable with Atari's), then as long as the chip knows what it's up to, it can write to memory.  But then 6502's memory access scheme may never leave you opportunities to do that without stalling the processor.  In the Great 8088/Z80/6500 Debate, efficient memory access is always listed as one of the 6502's strengths.  But that necessarily means that outsiders must tell the chip to sit tight for a second when they want a turn.

 

Now, some ARM-based chips also come with an impressive smorgasbord of goodies.  Renesas's RZ/A1 series comes to mind.  Besides its dozens of higher-level components, it also has ways to natively access RAM, SPI devices, and even flash RAM and removable flash devices.  Then again, that chip is powerful enough to emulate the entire Atari system by itself (while also playing a DVD and standing in for your car's ECU while spinning a dozen plates and standing on its head), so making it a slave of the Atari system is rather demeaning.

 

[_The Doctor__]

You want to play with an Atari bitd idea?

Stuff the bus letting the external unit handle all memory operations transparent to the on board chips who will simply execute what they will pull from that memory...

so that external unit will handle filling the memory and the on board Atari chips will only manipulate that data as needed. All Atari in the sense that team is giving the audio video et all... and you could possibly still have separate ANTiC access not only standard form but perhaps it's own memory completely. This is not the same as replacing the CPU in that the CPU is still executing code it's pulling from memory...

Edited September 15, 2019 by _The Doctor__

[E474]

Hi,

 

   I don't know enough about hardware to say if the ARM chip could provide DMA services, and I'm not clear on how@_The Doctor__'s bitd idea would actually work. 

 

   However, I've ordered a discovery board, and hopefully will be getting a Uno Cart too, so can have a go at exploiting the onboard ARM chip.

 

   Thanks for all the great ideas!

[+Stephen]

On 9/14/2019 at 8:23 PM, Kyle22 said:

If this could stream video from the PBI device or cart to ANTIC during DMA, then Dragon's Lair would be easy. All the videos from the original disc on the device's storage, and the game logic running on the Atari.

There would need to be a good communication channel between the two for best performance.

Great idea for a card for Incognito or proposed 890 expansion box.

 

 

We can already do that with the SIDE2 or Incognito or U1MB and Phaeron's video player.  No need for more new hardware to not support.  Just write the software for what we have had for the past 3 to 5 years.

[Kyle22]

On 9/15/2019 at 11:55 PM, Stephen said:

We can already do that with the SIDE2 or Incognito or U1MB and Phaeron's video player.  No need for more new hardware to not support.  Just write the software for what we have had for the past 3 to 5 years.

No, you can't. You can stream video, but the ARM chip effectively adds many more CPU cycles This gives the programmer many more options.