PBI R:Fi - Project Design/Build Log

[TangentAudio]

video from another project

 

 

Yeah, I saw that the other day. I considered going with the SIO approach as I'd be a lot further along in development by now, but it wasn't the direction I wanted to go both from an end product standpoint as well as a personal challenge standpoint.

[TangentAudio]

Either I'm getting old (yes), I've got too much going on in my life (yes), or this is just at the edge of being too complex to keep all the details straight in my head... So I've started to put together a specification which will serve as ongoing technical documentation, but more importantly provides me a place to think through design issues of the overall system. The diagram was a good start, but lacked a lot of the details I needed to keep track of for implementing the VHDL (and eventually the handler code).

 

It's still an early draft and I'm sure there are a few flaws and details not yet sorted out, but it's starting to take shape. Having a relatively good idea of where I'm going on 'paper' should help ease the process of developing the VHDL, and also opens up the process so others can see where I'm heading.

 

AtariPBIFPGAEngine-draft1.pdf

[TangentAudio]

I am still alive over here. I'm probably 8 hours in on VHDL implementation on the SPI/Dual Port RAM interface now... It was slow going at first trying to shift mental gears back into this project, and I had a couple of dead-end approaches that I had to back out of, but I think I'm headed in a good direction now. I think I now have a complete enough implementation that I can start running through verification to sort out design flaws and bugs. Everything is up to date on GitHub for anyone bored enough to follow along and critique my VHDL.

 

I think I have sorted out a workable approach for the SPI bus protocol, and have updated the spec to include some info on that. Also filled in some other details as I was working on the VHDL.

 

I'm in the middle of upgrading my install of Intel (Altera) Quartus Prime Lite from version 16 to 17, and I guess I'll find out if everything breaks or not... Hoping the problems I was hitting in the simulator are fixed in the latest version, but not holding my breath. [Edit: no luck, same error on simulation... ]

AtariPBIFPGAEngine-draft2.pdf

Edited May 10, 2017 by TangentAudio

[_The Doctor__]

taking voice notes//recordings during work and discovery then putting them to text / word processor with edited notes is a way good numbers of people have found in keeping with a project. culminating in a final technical document at product finish... I highly recommend that method..

Edited May 10, 2017 by _The Doctor__

[TangentAudio]

I've never really tried voice dictation for tracking details in my work. It's easier than ever these days to record audio (or video) since most of us have smart phones at our sides all the time, so it's really worth a try.

 

The document I'm writing is really serving more as a digital whiteboard than it is intended to be polished documentation. My mental process benefits from committing thoughts to some kind of medium and then shaping and refining them as a semi-tangible thing. I can do a lot of conceptual design without that step, but once a project hits a certain scale, there's something critical about that process that really helps me with iterative design. The process also helps to free up my mind to focus on a different aspect of the design as I'm no longer burdened trying to keep all the details of a particular aspect of it straight in my head. Another nice benefit is that I find it much easier to work on the actual implementation process once this is done.

 

I do find it fascinating to learn about other people's processes. Often someone else's approach is not suited to my preferred way to work, but every so often it sparks an idea that leads to a change in my own processes.

[TangentAudio]

I put in more time last night and early this morning and I'm finally starting to be on track with proper simulation/verification tools (Modelsim-Altera) and writing a real test bench for verifying my body of VHDL code. I still have a lot to learn about the simulation tools, but I'm making progress learning to write 'real' test benches in VHDL. I've made it this far in my programmable logic experience mostly using 'hand drawn' test waveforms in the overly simplistic simulators available... Though, in a co-op job that I had in the early 90s, I wrote Verilog test benches for a summer, but I've literally forgotten everything about that.

 

[+mytek]

I put in more time last night and early this morning and I'm finally starting to be on track with proper simulation/verification tools (Modelsim-Altera) and writing a real test bench for verifying my body of VHDL code. I still have a lot to learn about the simulation tools, but I'm making progress learning to write 'real' test benches in VHDL. I've made it this far in my programmable logic experience mostly using 'hand drawn' test waveforms in the overly simplistic simulators available... Though, in a co-op job that I had in the early 90s, I wrote Verilog test benches for a summer, but I've literally forgotten everything about that.

 

modelsim.PNG

 

I love what you are doing, and I really appreciate the excellent documentation you are creating along the way, but it makes me feel stupid at the same time

 

Can't wait to see where this project ends up.

 

- Michael

[TangentAudio]

I've been making progress pushing through on verification and debugging and I think I've now got the SPI bus/dual port RAM data pump interface working, at least in simulation. Had a handful of fussy details that took some tweaking to get right, but the change over to the better simulation tools was well worth the effort since it's highly scriptable and easy to iterate and test design changes.

 

Next up is writing some verification code for the Atari side of the interface, though it's fairly straightforward and I already have a proven and working PBI interface from my work last month, so it should be in good shape. I shouldn't be far now from wiring this up, uploading code to the FPGA, and writing some test code on both the ESP32 and Atari sides to try moving some blocks of data. My early tests will be boring but useful verification/stress testing/benchmarking tools.

 

[TangentAudio]

I decided to prototype up the connection to the ESP32 development board a different way than I had originally intended. The Altera FPGA eval board has headers for Arduino shields, to allow easy experimentation with the FPGA and existing Arduino I/O boards. I decided to use a blank prototyping shield to hold the ESP32. Now I have quite the ridiculous tower of PCBs stacked up behind the Atari. The final PCB will be much smaller than this mess!

 

This does kind of give me an idea for a different project, though - it might be neat to have a Arduino shield-compatible Atari PBI experimenter's board. An FPGA would provide GPIO/I2C/SPI/serial interfaces on the Atari PBI bus and would be used to experiment and prototype with electronics and software. Kind of a supercharged version of how I got my start in electronics and computers by interfacing with the Atari bidirectional joystick ports all those years ago. Pretty limited interest in such a thing, I suspect, but I think it's a neat idea anyway.

 

[+mytek]

At least it is a very 'neat' mess.

 

A PBI experimenter board would probably be a great asset to others wishing to design new PBI devices, something that seems to have a steep learning curve, hence the lack of utilization in the real world. I personally like the idea very much.

 

- Michael

[TangentAudio]

At least it is a very 'neat' mess.

 

A PBI experimenter board would probably be a great asset to others wishing to design new PBI devices, something that seems to have a steep learning curve, hence the lack of utilization in the real world. I personally like the idea very much.

 

That's a slightly different take on the concept than I was thinking, but it's a good idea. I was thinking something that would make it easy for a beginner to experiment with hardware from BASIC or another simple language, but it's hard to imagine someone choosing to do that on an Atari versus using a $20 Arduino and a modern PC to do it instead. However the one thing the Atari (like all of its contemporaries) had going for it was the immediacy and interactivity of the programming experience, which is lacking a bit on an Arduino since it's based around a cross compiler and the write-download-test-repeat methodology.

 

The idea of a "PBI jumpstart" board seems like a nice fit with the idea of developing an open PBI interface design and documentation package, and is a much more compelling reason to do it!

[Dropcheck]

Here's an interesting take on the discussion: Atari XL FPGA PBI Board

[TangentAudio]

Here's an interesting take on the discussion: Atari XL FPGA PBI Board

 

Cool, looks like someone's already gone down that path. While I might make some different choices on certain aspects of the design, that's more or less the same idea.

[TangentAudio]

I did a TON of work this weekend and I'm pleased to say I now have data moving between the ESP32 and the Atari! It took a lot of hours to debug the final details of the SPI bus interface and the dual port memory interfaces, but I found the last major nagging issue this morning and fixed it. Here's a video showing where things are currently (including some overview and review, not a lot of super deep technical details).

 

 

[flashjazzcat]

Looks fantastic!

[TangentAudio]

Just to note, the test/demo was not using any PBI BIOS routines for data exchange. The executable on the Atari was simply enabling the PBI device by writing to $D1FF, and directly manipulating the registers and mapped memories of the FPGA. I will eventually get back to the task of making things compliant to the Atari XL OS, but for now I'm mainly interested in proving out the FPGA without the extra layers of complexity that the OS and BIOS routines imply. Not only that but I'm pretty rusty at assembly language programming so I've been subconsciously avoiding getting into large 6502 asm programming tasks just yet.

 

I've been thinking about some other interesting possibilities involving mapping the dual port RAM on the Atari side. I've been toying with the idea of making a software-configurable memory map (via writes to FPGA registers) that would allow the dual port RAM to show up anywhere in the Atari address space as a linear chunk of RAM, overriding parts of the Atari's internal RAM. I am particularly interested in the idea of mapping the screen memory to a window of this dual port RAM, possibly allowing the ESP32 to directly blast data onto the Atari screen. I'm specifically thinking of a sort of web browser application which might use such a 'passthrough' mode to allow blazing fast text rendering, or maybe even graphics & text rendering in graphics mode 8. Maybe even directly to a VBXE? I'm not 100% sure if this hack is possible, as I haven't yet studied all the intricacies of how ANTIC performs its memory accesses. However, I think if the Atari 600XL memory expansion was able to essentially turn that computer into an 800XL it must be possible for the ANTIC to work with RAM hanging off the PBI, so it seems like it should work.

 

This FPGA only has ~48KB of RAM in it, but there are variants with more RAM (for considerably more $$ unfortunately, and I was hoping to step down to a less expensive variant for production, which implies even less RAM/ROM). But more RAM could open up possibilities of directly loading executable files or ROM images or whatever else via WiFi, and have them essentially immediately mapped to the Atari without having the 6502 do any copying of data.

[+Stephen]

Well, Phaeron's SIDE2 movie player shows the potential for directly slamming data into ANTIC via the PBI.

[TangentAudio]

Well, Phaeron's SIDE2 movie player shows the potential for directly slamming data into ANTIC via the PBI.

 

This would be a bit different. I understand that video playback hack to work with the 6502 continuously reading out from a single register of the IDE device to fetch data. What I'm thinking of trying is essentially a shared framebuffer - the Atari would have a display list pointed at a chunk of RAM just as it normally does when it's rendering a screen.. It's just that there would be a "back door" for the ESP32 to write data into the video memory without any interaction required on the Atari side.

 

To do it right and avoid tearing or other video display issues, it might require at least 2 pages of memory, and a page flipping scheme (which would require a tiny bit of 6502 interaction to flip pages) - or possible a scheme of gating the ESP32's writes to that video memory to only occur during the vertical blanking time.

[venom4728a]

Wow, this project is looking really cool!!!

 

Looking forward to watching more videos and reading updates as it progresses.

[TangentAudio]

So I couldn't let that idea of direct screen memory writes go, and I added a handful of registers and some logic in the FPGA to allow the Atari to program a memory window (defined by two 16-bit addresses stored in registers LBTM and LTOP), along with an enabling and mask register called LMAP.

 

My little tech demo (written in cc65) starts up and sets up the FPGA. It uses the contents of SAVMSC($58) to find out where the text screen is currently mapped, and sets LBTM to the same value. It then sets LTOP to half the screen size, and enables the linear memory map and proper address bits by setting LMAP. Then it just goes into a tight loop looking for a keypress and updating a counter at the bottom of the screen.

 

The entire upper half of the screen is mapped to the Master RAM, which is the dual port RAM normally intended to be the buffer of data from the ESP32 to the Atari. The ESP32 is running code similar to yesterday, but just blasting 1KB of data out on its SPI bus every millisecond. The ANTIC chip is none the wiser about the source of the bytes in the screen RAM and just displays it.

 

ONE caveat I've found is that I do not think the Atari RAM "underneath" where I've mapped the FPGA RAM is actually being disabled as I thought it should. I figured setting the PBI line EXTSEL=0 would allow a PBI device to overlay anything the Atari might have internally. However I was only able to get this hack to work by pre-filling the real Atari RAM with $FF before enabling the mapping (if you look closely you can see this happen with the slow conio printf routines at the start of the program, $FF looks like inverted right arrow blocks).

 

Anyway it still has some promise as a cool hack. I still see potential value in creating some kind of hyper-fast browser or file selector or something, where the ESP32 can essentially just treat the Atari as a very fast terminal.

 

Edited May 16, 2017 by TangentAudio

[Joey Z]

This would be a bit different. I understand that video playback hack to work with the 6502 continuously reading out from a single register of the IDE device to fetch data.

Actually the video player hardly has the 6502 doing anything related to the video. The 6502 sets up the CF card, and ANTIC reads out the video data with DMA. The 6502 is primarily handling audio only.

 

 

ONE caveat I've found is that I do not think the Atari RAM "underneath" where I've mapped the FPGA RAM is actually being disabled as I thought it should. I figured setting the PBI line EXTSEL=0 would allow a PBI device to overlay anything the Atari might have internally. However I was only able to get this hack to work by pre-filling the real Atari RAM with $FF before enabling the mapping (if you look closely you can see this happen with the slow conio printf routines at the start of the program, $FF looks like inverted right arrow blocks).

Setting /EXTSEL low should disable the RAM completely by inhibiting the /CAS line. Perhaps you need to check your wiring again? It sounds a bit like your FPGA is able to drive a low signal against the RAM's high, but not a high signal against the RAM's low. (and that you're not actually pulling /EXTSEL low.)

Edited May 16, 2017 by Joey Z

[TangentAudio]

Setting /EXTSEL low should disable the RAM completely by inhibiting the /CAS line. Perhaps you need to check your wiring again? It sounds a bit like your FPGA is able to drive a low signal against the RAM's high, but not a high signal against the RAM's low. (and that you're not actually pulling /EXTSEL low.)

 

OK, so I was right about how I thought /EXTSEL should behave, so something must be amiss somewhere. The behavior I'm seeing definitely looks like bus contention, and since it's common for output drivers to be able to sink more current than they can source, '0' usually beats '1' in a fight. That's what made me try filling the internal RAM with FF's just to see if suddenly it worked (which it did).

[TangentAudio]

Does anyone know the precise behavior for the EXTENB pin coming out of the MMU? And is the MMU for the 800XL known to be identical to that in the 600XL? Could there be a difference in behavior for the EXTENB output (pin 16), considering the 600XL was a 16KB machine intended to be upgraded with the 1064 memory module on the PBI?

 

I have a JEDEC file for it (and have successfully programmed GALs to replace the MMU PAL) but I have not seen a schematic, truth table, or other visual representation of what it's doing internally. PAL/GAL chips are simple enough and I'm sure I could reverse engineer it from the JEDEC if I had to, but I'd rather not if someone already has it drawn up.

 

Has anyone ever confirmed that the U1MB+, which replaces the MMU chip, works the same as a stock XL with regards to EXTENB?

 

I ask because the /EXTSEL logic directly involves EXTENB (see attachment), and I'm wondering if that memory bus contention issue I was seeing might actually be related to the fact that I've got a U1MB+ in my development machine, and perhaps it behaves differently.

 

 

 

 

[TangentAudio]

I did find a source for the MMU logic, thanks to some work in the past by Bob Woolley.

 

My theory above doesn't make much sense now that I've looked at the schematic again after a cup of coffee. Of course /EXTSEL=0 should inhibit /CAS regardless of the state of EXTENB, so it doesn't seem likely U1MB+ or anything else is an issue, and I probably have something screwy on my prototype. What seeing this logic possibly does help confirm is why I have proper functionality in the D800-DFFF window even if I may have a non-functional /EXTSEL on my board. It looks like the EXTENB logic includes D800-DFFF, so it's entirely likely the MMU has actually been the thing inhibiting /CAS for D800-DFFF, all the while masking an issue on my prototype until I started testing outside of that window. I'll go hunting tonight and I bet I will find a dumb wiring error.

 

This contains a version of the 800XL PAL logic in PALASM, at least Bob's interpretation of it. I've been redrawing this part of the 800XL schematic to make a nice little one page quick reference, and I'll include the equations in the MMU portion.

 

 

Name 800XL MMU;
Partno CO61618;
Date 02/25/99;
Revision 00;
Designer Bob Woolley;
Company Atari Rulz!!;
Assembly 1200XL;
Location U14;
Device P16L8;

/******************************************************************/
/* Stock Atari XL/XE MMU */
/* */
/* */
/******************************************************************/
/* Allowable Target Device Types: 16L8 */
/******************************************************************/

/** Inputs **/

Pin 01 = A11 ; /* address bit 11 */
Pin 02 = A12 ; /* address bit 12 */
Pin 03 = A13 ; /* address bit 13 */
Pin 04 = A14 ; /* address bit 14 */
Pin 05 = A15 ; /* address bit 15 */
Pin 06 = MAP ; /* PB7 diagnostic bit */
Pin 07 = RD4 ; /* right cart. @ $8000-$9FFF */
Pin 08 = RD5 ; /* left cart. @ $A000-$BFFF */
Pin 09 = REN ; /* PB0 OS ram enable */
Pin 11 = REF ; /* DRAM refresh */
Pin 14 = MPD ; /* Math Pack Disable */
Pin 18 = BE ; /* Basic Enable */


/** Outputs **/

Pin 12 = !S5 ; /* left cart. select */
Pin 13 = !BASIC ; /* Basic ROM select */
Pin 15 = !OS ; /* OS code select */
Pin 16 = !CI ; /* DRAM CAS inhibit */
Pin 17 = !IO ; /* I/O select @ $D000-$D7FF */
Pin 19 = !S4 ; /* right cart. select */


/** Logic Equations **/
/** # is or **/
/** ! is not **/

S4 = !A13 & !A14 & A15 & RD4 & REF;/* RD4 and addresses $8000-$9FFF */
S5 = A13 & !A14 & A15 & RD5 & REF; /* RD5 and addresses $A000-$BFFF */

IO = A12 & !A11 & !A13 & A14 & A15 & REF; /* addresses $D000-$D7FF*/

CI = !A13 & !A14 & A15 & RD4 & REF /* right cart. */
# A13 & !A14 & A15 & RD5 & REF /* left cart. */
# A13 & !BE & !A14 & A15 & !RD5 & REF /* BE and $A000-$BFFF */
# OS /* OS addresses */
# A12 & !A11 & !A13 & A14 & A15 & REF /* I/O addresses */
# !REF; /* memory refresh */

OS = A13 & A14 & A15 & REN & REF /* addresses $E000-$FFFF */
# !A12 & !A13 & A14 & A15 & REN & REF /* addresses $C000-$CFFF */
# A12 & A11 & !A13 & A14 & A15 & MPD & REN & REF /* addresses $D800-$DFFF */
# A12 & !A11 & !A13 & A14 & !A15 & !MAP & REN & REF; /* addresses $5000-$5800 - mapped */

BASIC = A13 & !BE & !A14 & A15 & !RD5 & REF; /* BE and $A000-$BFFF */

Edited May 17, 2017 by TangentAudio

[_The Doctor__]

it's always best to go with stock baseline machines and work your way up but.... who knows discovery can happen if you go the other route... you never know what you will uncover!