PBI R:Fi - Project Design/Build Log

[flashjazzcat]

No rush, I won't have any time to poke at this until late next week at the soonest. Glad it turned out to be fairly obvious at least!

 

No problem. ICHIDZ ($20) contains an index rather than an address, so presumably what he means is checking the first character of the string at ICBALZ/ICBAHZ ($24/25). Anyway: I've added that check and will PM it across for testing when you get time.

[AtariGeezer]

Thanks for this thread. I know nothing at all about the PBI and only a little about CPLDs so I only understand a very small portion of the details, but I am very much enjoying following along on the saga!

Same here, love learning new things. Hope to one day start designing/building new projects, some even from dreams...

For the past 5 days I've been reversing the pics that Mr. Atari was gracious to post of the 1450XL's Parallel Disk Drive Controller into a readable schematic. Seeing how that connects to the internal Parallel Bus is amazing...

 

Back to the topic

[Dropcheck]

Same here, love learning new things. Hope to one day start designing/building new projects, some even from dreams...

For the past 5 days I've been reversing the pics that Mr. Atari was gracious to post of the 1450XL's Parallel Disk Drive Controller into a readable schematic. Seeing how that connects to the internal Parallel Bus is amazing...

 

Back to the topic

 

I think some people would pay for those schematics. Even if there was an error or two. I took one look at the wire wrap and knew I would never wire wrap more than four wires ever. A lot of people swear by wire-wraping. A lot more swear at them, me included.

[AtariGeezer]

 

I think some people would pay for those schematics. Even if there was an error or two. I took one look at the wire wrap and knew I would never wire wrap more than four wires ever. A lot of people swear by wire-wraping. A lot more swear at them, me included.

Not to worry, I do plan on posting it soon in a new topic: "Need Help with 1450XL Parallel Disk Drive Schematic" as my eyes don't see so good with some wires too close together The Hand Drawn schematics of the 1450XL Tong mobo do fill in some gaps, but not all...

[Dropcheck]

Just saw this on another site. Wonder if once you have the wireless nailed down, it might be possible to add wired connection too. Hey, I want my cake and to eat it too.

 

Still..... Keep up the work regardless.

[TangentAudio]

Just saw this on another site. Wonder if once you have the wireless nailed down, it might be possible to add wired connection too. Hey, I want my cake and to eat it too.

 

Still..... Keep up the work regardless.

 

It's definitely crossed my mind, I've been aware that the ESP32 had support for wired ethernet.

[TangentAudio]

 

No problem. ICHIDZ ($20) contains an index rather than an address, so presumably what he means is checking the first character of the string at ICBALZ/ICBAHZ ($24/25). Anyway: I've added that check and will PM it across for testing when you get time.

 

I was trying to puzzle my way through that last night with the OS reference and Mapping Atari and was wondering what it was indexing.

[_The Doctor__]

Looks like collaboration as suggested is a success.. as we go along and weed out what got in the way of what and how it was fixed it would serve us well to have the PBI device success list, what has been fixed and why it should be in the checklist to prevent a fail in the future, and devices that need patching or fixing and why... like the Black box taking all the id's etc...

 

nice catch indeed! FJC quick to help and quick to work! +1

Edited April 19, 2017 by _The Doctor__

[TangentAudio]

Looks like collaboration as suggested is a success.. as we go along and weed out what got in the way of what and how it was fixed it would serve us well to have the PBI device success list, what has been fixed and why it should be in the checklist to prevent a fail in the future, and devices that need patching or fixing and why... like the Black box taking all the id's etc...

 

nice catch indeed! FJC quick to help and quick to work! +1

 

It would be really nice to end up with a modern and up-to-date PBI reference out of this project - both documentation and a starting design.

[flashjazzcat]

Agreed. Although in hindsight it's rather obvious what I did wrong, when implementing these things in the first place there's little in the way of reliable references. Too often one relies on disassembly of existing code (assuming something can be found) to pick up clues.

[TangentAudio]

Agreed. Although in hindsight it's rather obvious what I did wrong, when implementing these things in the first place there's little in the way of reliable references. Too often one relies on disassembly of existing code (assuming something can be found) to pick up clues.

 

That's it in a nutshell - there is no single definitive source of PBI documentation that contains the right mix of factual information from the scant official sources and real-world experiences from the small number of people who have developed working PBI hardware and handler code. The articles that have been written do contain many nuggets of useful information, but to some extent they either suffer from being out of date, or the authors not having been privy to the wider pool of understanding we now have of some of the problems inherent in the bus (e.g. stuff that Hias has talked about in this thread).

 

A lot of these small details may sit languishing on someone's computer from a project they did, either intentionally because they don't want to share their work or accidentally because they figure nobody else is interested in the details. Or worse yet, they disappear into the sands of time because the only copy gets destroyed or lost in the shuffle over the years.

 

I've been thinking a bit about what the best format would be for such a thing. A simple document is nice because it's self contained and easy to keep track of a single file - but it's hard to make it a 'living' document where new information can be added by multiple authors. A wiki would be nice because it allows it to be updated with new information as needed, but unfortunately it requires hosting and the long term safety of the data is questionable. We could consider expanding the wikipedia PBI article, but a lot of the material we might want to reference (e.g. the Earl Rice ANTIC articles) is copyrighted, so that's a problem. Ideally we end up with something where new examples and reference code and designs can be tacked on or referenced as people make new projects and are (hopefully) willing to share.

 

A Google Doc might be good, since multiple people could collaborate on it, but again it has a dependence on their long term hosting and ultimately the file does need to be 'owned' by an individual, and it's hard to make it an Atari community asset.

[Dropcheck]

Which ever physical form the information ultimately exists in, probably the only way to insure that it survives a single point failure is by auto updating mirroring on multiple sites. I would be willing to host one such mirror.

[TangentAudio]

Which ever physical form the information ultimately exists in, probably the only way to insure that it survives a single point failure is by auto updating mirroring on multiple sites. I would be willing to host one such mirror.

 

Github is also a good choice for longevity as projects can be forked and live on past one original author.

[Dropcheck]

 

Github is also a good choice for longevity as projects can be forked and live on past one original author.

 

I agree as well. But there has been unrest over the last year or so, as Github has attempted to cater to its paying customers at the expense of the smaller free user base. If I remember correctly there was unhappiness that some previously free features of the site were being withdrawn or deliberately crippled unless the user was a paying user. Haven't heard any recent info on that, but Github as influential and robust as it is, is still just one site.

 

There's no easy solution. Every option has it's own short comings.

[HiassofT]

but Github as influential and robust as it is, is still just one site.

And, thanks to the beauty of git, even this doesn't matter much.

 

Every user who cloned the git repository will have a full copy of all the files and the histories on his local harddrive(s). So a mess like what happened with AspeQt can't happen.

 

And all users can easily make their local git trees publically available. You just need some linux box with network connectivity, ssh (so you can push you git trees/updates) and some web server to make the trees (read-only) available to the public.

 

so long,

 

Hias

[Dropcheck]

Just to bump this back onto the first page. And to see if there is an update.

[TangentAudio]

Just to bump this back onto the first page. And to see if there is an update.

 

I won't be back into it until later in the week due to some work travel for our huge yearly trade show. Before I left, I did have a chance to try out some test code from FJC and unfortunately it didn't seem to help out the conflict situation much, so we need to look at it a bit deeper.

 

I did make a small change to allow the PBI device ID to be set from DIP switch, to make it easier to test out some different scenarios. I also took a little time to get everything else pushed up to github before I left. I had hoped to find some time to do more research and reading while I've been traveling but free time and leftover brain cells have both been hard to come by.

[TangentAudio]

Finally back home from a week in Las Vegas. Hoping to get down to the lab today and boot up the Atari and see where I left off with this project, and figure out if I still know how to do any engineering.

[_The Doctor__]

Sometimes people leave more in Vegas than they imagined they could... here's hoping you still remember your name, and what those glowing screens are in the lab.!

[TangentAudio]

Sometimes people leave more in Vegas than they imagined they could... here's hoping you still remember your name, and what those glowing screens are in the lab.!

 

This was my 7th trip and thankfully I am fairly well immune to the usual trappings of Vegas by now, but it was still a long and exhausting week of trade show work, travel, and sleep deprivation.

 

I got down to the lab for a bit yesterday and did start to poke at the FPGA code a bit. I decided to start working on the ESP32 side of the interface, which I've been planning as a SPI interface. I spent a while poking at the Altera SPI component that they offer, and I'm not entirely convinced it's the best choice for how I want to implement the interface. I really want to build a DMA-like interface between the ESP32 and the Atari, so that the ESP can just read/write memory buffers without any interaction from the Atari (at least on a byte-by-byte level). The Altera SPI component is really more suited to making a byte-at-a-time interface available as a standard memory-mapped peripheral. It wouldn't be hard to connect it to the PBI, but I wouldn't be very happy with the resulting efficiency.

 

It wouldn't be that hard to just make my own SPI interface, and connect it up to a dual-ported RAM in the FPGA, so that essentially the Atari and ESP could read and write independently of one another, and would use some external handshaking to control the overall flow of data.

[TangentAudio]

I've been making a little bit of progress on the design of the SPI DMA engine, which will be the interface in between the ESP32 WiFi chip and the Atari PBI. My goal is to design an interface which is high performance from both the perspective of the Atari and the ESP32, to allow (relatively) high throughput. This will be done by having the Atari write to a block (or blocks) of memory before initiating the SPI transfer to the ESP32, and by having the results from the ESP32 'magically' show up in a buffer that the Atari can then read or manipulate. The transfer of the memory blocks between the FPGA and the ESP32 will occur with no intervention from the 6502, once started. Transmit and receive may also occur concurrently if desired.

 

The design is still only slightly better than a sketch on a napkin at this point, but I have started to build the VHDL code for the FPGA, moving towards this goal. I'm sure more details will shake out as I get into it, but minus a lot of details this is the direction I am heading in. It's built around dual port RAM that's available in the FPGA. This is a RAM element that has two independent address/data interfaces, allowing reliable simultaneous access. Though actual simultaneous access is not strictly required in this case, it does simplify some aspects of the design internally.

 

[TangentAudio]

Made some fixes, additions and refinements, probably at the expense of overall clarity of the diagram.

 

• Now shows bank switching for the DPRAM chunks, so more than one 512 byte buffer can be used to increase efficiency. I probably won't implement this right away, but I wanted to capture the concept.
• Shows interrupt logic so the DMA completion can trigger an Atari interrupt. Also probably won't do this right away.
• Added the ability for the SPI side to read/write control and status registers for the SPI state machine. Have to work out contention with the Atari being able to write to the same registers. Added another chip select on the SPI side for this, rather than implementing a command word in the protocol.
• Fixed D600-D7FF (accidentally showed it extending to D800 originally)

 

[TangentAudio]

Making slow but steady progress on realizing the above diagram in VHDL. I've only been able to find an hour here or there to poke away at it this week (too many "real life" distractions), but I'm starting to get my head around it and hopefully soon the design will start to gel. Once I can overcome the inertia to get rolling on this project again, hopefully the momentum will help me pick up speed. It will be exciting to starting slinging blocks of data back and forth between the Atari and the ESP32!

[w1k]

good luck with progress

[w1k]

video from another project