Search the Community
Showing results for tags 'PBI'.
Found 10 results
-
A couple of months ago I decided to have a crack at writing a new BIOS for Ultimate 1MB from scratch. Its purpose was simply to facilitate a bootable version of the WIP Graphical OS in ROM and add some extra PBI BIOS options, but the project quickly ran away with itself and became an exercise in completely re-thinking just about every part of the functionality. The new BIOS offers: The ability to set the date and time from the setup menu Dual configuration profiles Categorized menus covering system settings, hard disk, device setup, etc Turbo-Freezer compatibility Customisable shortcut keys OS-independent Ultra-speed SIO for serial disk drives Optional BIOS logo screen and boot device selection menu Optional flash write protection System information page displaying CPU type, audio/video hardware, etc BIOS Plugin API for diverse hardware control (Ultimate 1MB only) Variable SpartaDOS X ROM sizes (192, 256 and 320KB), and the ability to boot the WIP Graphical OS (when 192KB SDX is used) So this is a beta version of the new (alt) Ultimate BIOS, provided with a new (beta) version of uFlash which is designed to handle both original and new BIOS versions (and the upgrade process), a (required) PBI BIOS update, and some documentation. I've also thrown in a complete Ultimate 1MB ROM with the GOS intended for testing in Altirra (or on a real machine if you're feeling brave). Ultimate BIOS Beta 0.24 Release.zip You'll notice the word 'beta' crops up a lot. This is BETA software, so please ensure you have a means of recovery in the event something goes wrong with the BIOS flash, or something unexpected goes wrong with the BIOS. Although the last couple of builds have been well tested, it's a BIOS and is therefore critical to whether your machine boots up or not. I can't stress this enough, and I do not want to hear people complaining about bricking their machines and having no way to recover. A USB flash ROM programmer is an absolute must if you want to test this on real hardware. The sensible procedure is to back up your entire Ultimate 1MB ROM first so that you can go back to it if you need to or if you simply don't like what you end up with. You can do this in-situ with uFlash or with your USB programmer. The (draft) documentation outlines the upgrade procedure, and you must upgrade both the main BIOS and the PBI BIOS both at once. That means load up uFlash, flash BIOS24.ROM to the "BIOS" slot and ULTPBI13.ROM to the "PBI BIOS" slot. Then do a power-cycle. The NVRAM configuration data of the original BIOS is completely incompatible with the new one, so although your system clock should remain valid, nothing else will. You'll be prompted to set things up again after the upgrade. The defaults chosen (i.e. stock RAM) will be subject to change in the final version, as will anything else I feel like changing, although the OS ROM, BASIC and XEGS slot descriptions (which should survive the upgrade) won't change position again. Things that don't work or only work partially or don't work at all: Boot device menu: works, but isn't finished "Redirect D1:" in the PBI BIOS menu is not implemented yet Other stuff This became such a gargantuan task that I just want to leave the beta out for a week or two and do other things to get over it, before fixing what needs fixed and getting on with the new (alt) XEX loader, which is about half done but will take a while to complete. Lastly, I want to offer massive thanks to Phaeron, Hias and Prowizard. The assistance they have provided in terms of testing, ideas, and technical insight was really fantastic, and without them, some of the neat features present just wouldn't exist at all. And had Hias not kindly agreed to let me use his High-Speed SIO code in the PBI BIOS (more or less verbatim), there'd be no High-Speed SIO. Thanks also to MrFish for valuable feedback and ideas on the UI, and of course to Candle himself for the hardware and original firmware. The sole purpose of this new, alternative BIOS is to get even more functionality from this fantastic hardware, taking inspiration from his initial achievements. I've probably forgotten stuff, but it's late, so - enjoy. PS: Incognito BIOS to follow shortly.
- 1,666 replies
-
- 18
-
-
-
- Ultimate 1MB
- Incognito
- (and 2 more)
-
It's pretty well known that the 800XL's video port is missing the chroma signal, and that it's a simple mod to put right. But I was recently toying with the idea of experimenting with hardware on the PBI. (Don't get excited, it'll probably come to nothing). However, I found that the PBI connector on the 800XL is missing a 5V supply, which greatly restricts what can be done without running additional cables to the SIO or joystick ports. Like the chroma, it's a simple mod to add the 5V (which is present on the 600XL), but are there any other similar omissions on the 800XL that I've not met yet? And has anyone actually added the 5V to their 800XL's PBI, or is there no point because no hardware appears to use it?
-
Hey all, I'm putting a query out to see if anyone has an interest in making XL BOSS, or a forward compatible version of OS B with PBI for the Ultimate 1 MB. I did various tests, and even confirmed with Jazzcat that PBI functions of XL Boss are not working for it, or non-existent. Now the rational for my query to make it PBI supported is this. I found that the game ENCOUNTER!, *Which has other revisions that work with the Base XL version on the Aug 2019 rev of the U1MB update works with other revs of the game. Sure, you'd think that would be the end of that knowing other copies work. But what if you ran into a game that was not? Or just needed to have that straight up backwards 800 compatibility, other than the OS B PAL or NTSC rev. For some reason, the XL Boss rev 2 works perfectly with loading up this un-patched version of Encounter! Now don't get distracted by me repeating this one game. I can live with the work around. What I'm looking for though it a community level update to XL Boss to use with the U1MB on a routine basis with PBI support. The original thread I found on XL BOSS is noted below. I've already had some discussions with Nezgar, and it does seem like a plausible idea to do. There's a few other features of XL Boss that are meaning full to use, and there's even many who've tried to use XL BOSS, but I can't find mention of quirks with PBI. NOTABLE TESTS RAN: Equipment: | Atari 800XL - U1MB | SDMAX - SIO - Gavin SIO board latest rev. | Side test with, same results as U1MB Boss Xl rev. Atari 800XL with OS rom replaced with patched HSIO and Boss XL with reverse Option only mod | Game: Encounter 3 versions ran against the default u1mb OS choices (excluding XEGS) - Either lead to black screen, start screen, but locks on starting the game. U1MB CHANGE: Replaced XEGS with Boss XL Rev 2. - Game runs as normal. --------------------------------------------------------------------------------------- Load Boss only, no cart, no SIO option, loading Sparta up. - Sucess OS works with Sparta seemingly normal. Load Boss with SideCart2 - Cart only mode and ATR mode - Unable to see it - Alternatively J.S.C. ran some inquiries for PBI fumction, and nothing indicated they we're found by the os. Keep in mind, this focus is not on the game, as much as it's an inquiry to make XL BOSS a possible alternative OS for the U1MB. Thanks for your input all!
-
The PBI bus on my 800XL always held magical and mysterious powers... It seemed to be the key to unlocking unlimited potential of my Atari. In my earliest years with the XL (age 9-13 or so), I didn't really know much about what lay behind the port cover. As I got a little older, I learned about the products like the Multi I/O and the Black Box which could be plugged in, but these were always priced out of my reach. As it would happen, I was destined to eventually follow a career path of software & electronics engineering, but my understanding of topics like parallel data buses would not come until I was a bit older yet, and had already moved on from the Atari to my first PC. Over the many years since then, I've gone on a few "nostalgia benders," digging up my old Atari gear and playing around with it for a while. Each time, I'd idly thought about maybe doing a PBI bus project, just to "check it off the list" so to speak. Well, this time I'm hoping to actually make it a reality, and I've started some work on a project that I think will blend the "old" (being the Atari) and the "new" (being some modern technologies I've been working with on other projects) in interesting ways. I've debated whether I should labor away in the dark without sharing any info until I reach some arbitrary milestone, or share a progress log to get feedback, help and motivation from folks here. I've opted to try the latter. So, I present the very first fledgling steps of my PBI bus to WiFi adapter for the 8-bit. I'm basing it on somewhat absurdly powerful but relatively inexpensive technology (an Espressif ESP-32 - a dual core processor standalone WiFi/Bluetooth module, and a small Altera MAX 10 FPGA). This is a massive pile of technology compared to the Atari, but I've been developing on the ESP32 for a few months on another project and am pretty familiar with it, and I've wanted an excuse to do a small FPGA project for a while now. I like the idea of combining these things. My initial goal is to make a wifi coprocessor for the Atari, with the ESP32 doing most of the heavy lifting for dealing with TCP/IP connections. In the initial incarnation, I'd like to present it to the Atari as an R: compatible interface, so it can be used right out of the gate as a replacement for an 850 + Lantronix device, except hopefully much faster. This way it can be used with BBS and terminal software. Longer term goals? Well, the sky's the limit really. The ESP32 has all kinds of interesting hardware support in it, and I've used much of it for another project. SD cards, audio, serial ports, I2C, Bluetooth, etc. There's a ton of potential to make it a PBI-based disk drive for example. Combined with the capabilities of the FPGA, it opens a lot of doors to doing interesting things. The daydreaming is great, but I'm trying to keep focused and meet a reasonable goal and then see where the project goes. My rough architecture is that the ESP32 is going to communicate with state machines in the FPGA over a high speed SPI bus (it has no parallel buses). The FPGA will mediate between the slow Atari parallel bus and the high speed SPI bus. The FPGA I've chosen has a bunch of RAM and Flash ROM elements in it, so it can contain shift registers or dual ported RAM to aid this, and it can also contain the small amounts of PBI device handler code that need to be mapped in. I'm breadboarding the first version because there are a few unknowns, and sometimes it's just easier to go old school and hand-wire stuff. I started this process last night, wiring up the address and data buses to the necessary level-shifting bus transceivers, because the Atari is a 5V system while the FPGA and the ESP32 are both 3.3V. I also have the FPGA eval board and the ESP32 development module positioned on the breadboard, but not yet connected.
- 174 replies
-
- 20
-
-
Good evening, everyone, I've been wondering, especially since Dropcheck has started inquiring about the Atari's PBI, what the advantages and disadvantages are between the PBI and the cartridge interface itself? What types of devices are best suited for one I/O platform over the other? I imagine from a modding perspective, a cartridge-based mod would have a much broader usability factor since not every Atari 8-bit has a PBI interface— but every Atari DOES have a cartridge port! For me, the primary drawback to these cartridge-based mods is that you only get to have one mod in play at a time. While there are a few pass-thru mods, the reality is that I don't see my utilizing the USB cartridge, the Bluetooth cartridge, and my SpartaDOSX cartridge with MacRorie's R-Time8 cartridge all in a single session, even though that would be something I totally seem myself utilizing. Yet all of these could be in simultaneous use, should someone develop an interface along the lines of the 1090, where the USB cartridge would become a PBI card-based solution, as would the Bluetooth cartridge— both operating through the PBI lines. And wouldn't it be convenient to be able to set something like the RapidUS to card-based, as well? However, with the 65/130XE and their ECI port, it seems like any 1090-like expansion solution would need to support a cartridge port. Anyhoo, I was just wondering what the technical advantages and disadvantages were between the PBI and the cartridge interface insofar as mod development is concerned...? Submitted for your perusal and consideration, Tim
-
Good morning, AtariAge'rs! Has anyone ever found or developed a replacement adapter that will allow ICD's MIO to be connected to the 130XE? If so, could you point me to where I can purchase one? Thank you, in advance! --Timothy Kline
-
Can anyone explain why the PBI includes the CAS/RAS lines? It has the full 16-bit address bus, so these seem superfluous. As I understand, EXTENB will go high when there is an address on the bus from the CPU and then I'm assuming it uses the full 16-bit address space.
-
Is it possible to craft a PBI or an ECI interface in an XEGS? Duplicating the cartridge connectors won't be that hard, but how about the rest of the PBI makeup or alternatively the ECI? Is anything missing? (apart the Audio in for the ECI) I remember the MPD was kind of messed up on XEGS to allow for Missile Command select (or was that EXTSEL)
-
Not referring to S-Drives and other SIO solutions. I have only been able to get the MyIDE family working with SD cards in addition to compact flash. Has anyone been successful with anything else? SIDE cart, maybe? I don't have one of those -- do they support MyDos as a regular hard drive? -Larry
-
This is a project idea we were chatting about on ##Atari today. The basic idea is that we make it possible for PBI devices to take over the system bus to perform DMA transfers at up to 1.7 megabytes per second. This is done by hooking into the way that ANTIC stops the CPU with a small riser board, and connecting /HALT and a new /DMA signal to two currently unused pins on the PBI. The device protocol would work like this: when a DMA transfer is desired, the device asserts /DMA. Every cycle that starts with /DMA asserted is a DMA cycle for the device *unless* /HALT was asserted before the cycle began, in which case the device has to relinquish to ANTIC. Devices can use the presence of /HALT at a high level during a read of the device's registers to detect whether DMA is present; if not, devices can fall back to programmed I/O. I whipped up a quick board layout for this; the board is also designed to generate a "clean" phi2 output as well as allowing the use of a W65C02 or W65C816 instead of 6502C. It does not support other 6502s or 65C02s which do not have the /BE input. Thoughts?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord