1090XL remake

[reifsnyderb]

Just now, _The Doctor__ said:

In any event low enough value won't get the job done? Even approaching zero?

The resistor would have to be on the PBI device.  So, the MMU and ANTIC would both be on the wrong side of the resistor.  If a resistor were to be put between the MMU and ANTIC, I doubt a resistor could be high enough to take the stress off of ANTIC and yet low enough to work properly.  But, I am not an electronic engineer.

 

The problem really is that Refresh goes to the MMU and the PBI.  To safely use the Refresh to turn off the MMU, from the PBI, there would have to be a buffer between ANTIC and the MMU.  This buffer would have to have the ability to be turned off from the PBI.

 

Keep in mind that devices are shorting Refresh to ground, from the PBI, and it does work.  This is how the 512K+ PBI memory upgrades work.  Supposedly, people familiar with ANTIC's design confirm that it's safe.  My personal feeling is that I'd rather not stress out a 40 year old chip that is not being made anymore.

[_The Doctor__]

12 minutes ago, reifsnyderb said:

The resistor would have to be on the PBI device.  So, the MMU and ANTIC would both be on the wrong side of the resistor.  If a resistor were to be put between the MMU and ANTIC, I doubt a resistor could be high enough to take the stress off of ANTIC and yet low enough to work properly.  But, I am not an electronic engineer.

 

The problem really is that Refresh goes to the MMU and the PBI.  To safely use the Refresh to turn off the MMU, from the PBI, there would have to be a buffer between ANTIC and the MMU.  This buffer would have to have the ability to be turned off from the PBI.

 

Keep in mind that devices are shorting Refresh to ground, from the PBI, and it does work.  This is how the 512K+ PBI memory upgrades work.  Supposedly, people familiar with ANTIC's design confirm that it's safe.  My personal feeling is that I'd rather not stress out a 40 year old chip that is not being made anymore.

and since shorting works approaching zero resistance plus trace resistance can provide minute protection you are looking for.

Consider the Julia buffer cable that was PBI side near the computer, even though currently there is a buffer inside the 1090. You can have a split approach where pick offs could go to a connect board attached to PBI or ECI port feeding your cable.

Edited April 18, 2023 by _The Doctor__

[+Stephen]

3 hours ago, reifsnyderb said:

I decided to put my 1091XL/XE Expansion System board together tonight...with all 5 card edge connectors installed.   🙂

 

Looking from front to back (or right to left...depending upon your perspective)...

 

1.  Empty

2.  XE Compatibility Board to recreate the /EXTENB signal that the XE doesn't supply.

3.  Firmware Board.  Right now, it loads PacMan if the Select key is held down when booting the system.

4.  320k SRAM board.  Upgrades my 16k 600XL to 320k.   🙂

5.  CX85 Numeric Keypad Interface.  Plug in the CX85 Numeric Keypad here.   🙂

 

The 1091, and all boards, are tested and functional.

 

Edit to add:  With the exception of the XE compatibility board, all boards will work on a 1090XL.

 

The firmware board is very versatile.  I have, as a test, configured the firmware board to load Altirra BASIC.  In one test, it was also able to upgrade the floating point math pack.  Other uses could be to load a RAM-based OS from the card, install an 80 column software-based system, add fast SIO to the existing OS, etc.

 

Now this is just unbelievably cool.  If we had this when the 400/800 was out, the Apple II wouldn't have stood a chance.  At least now we can live out that alternate reality, and experience the what if.  Thanks to all you hardware guys making this possible.

[reifsnyderb]

2 hours ago, _The Doctor__ said:

and since shorting works approaching zero resistance plus trace resistance can provide minute protection you are looking for.

Consider the Julia buffer cable that was PBI side near the computer, even though currently there is a buffer inside the 1090. You can have a split approach where pick offs could go to a connect board attached to PBI or ECI port feeding your cable.

The 1090 buffers the refresh.  With the XE compatible (extended?) version of the 1090 board I replaced the transceiver with an ATF16V8 and used the Refresh line, on the 1090 side, as a disable line so that compatible RAM boards could have their memory shut down in a manner similar to the function of the /EXTSEL line on the PBI.  I chose the /refresh line because none of the legacy boards used it.  Since it's a buffered line, the ATF16V8 can ignore it or, if the ATF16V8 is re-programmed, the function can be re-configured to be exactly as per the original 1090 specifications.

 

A possible option would be to have one of the 1090 card slots configured so that it's connected directly to the /refresh line for cards that abuse it's function to short out /refresh and shut down the MMU.  The only tradeoff would be that newer cards wouldn't be able to shut down and remap any base memory on the card in that slot.  Though, if jumpers were installed, the slot could be configured either way.

 

Here's the schematic for the ATF16V8 chip on both the 1090 and 1091.  It's mostly used as a transceiver.  However, if pin 11 is set low by an XE Compatibility board, /EXTENB is no longer an output from U7.  This allows the XE Compatibility Board to create the /EXTENB signal with it's ATF16V8...which is acting as a MMU.  (The XE doesn't have an /EXTENB signal.  This results in memory cards not functioning in the 1090 as they require an /EXTENB signal.)

 

Edited April 18, 2023 by reifsnyderb

[rkindig]

I don't know if I've missed it, and if so I apologize, but is the 1090 expansion remake available to purchase anywhere?  I'd really like to get one.

 

thanks!

 

Randy, co-host ANTIC (ataripodcast.com) 

[reifsnyderb]

12 hours ago, rkindig said:

I don't know if I've missed it, and if so I apologize, but is the 1090 expansion remake available to purchase anywhere?  I'd really like to get one.

 

thanks!

 

Randy, co-host ANTIC (ataripodcast.com) 

PM sent.

[reifsnyderb]

I partially assembled a 1090XL/XE board today.  I say "partially" because it is fully functional with all cards except for the serial/parallel card....that hasn't been remade anyhow.  The 12VDC components are missing.  Also, missing is the front LED and it's resistor.  Pictures of an original 1090XL don't show these to be installed.  Missing are the diodes from CR17-CR24 as pictures of an original 1090XL don't show those to be installed.  (These diodes appear to be additional protection for the data lines...which are already protected via the 8 100 ohm resistors.)  U4, U5, and U7 are also not installed.  U4 and U5 are alternate transceivers for U4A and U5A (installed).  It's nice to have an option for alternate components with the chip shortage.  U7 is not installed, either.  Originally, U7 was the transceiver for many of the control lines.  I put an ATF16V8B in place of U7A so that it can be programmed for Atari XE compatibility.  If U7A is removed and U7 is installed, it's possible to restore this board to function 100% like the original 1090XL.  (A jumper would have to be installed at JP1 and R15 removed, as well.)  This board also has the ability to have a connector installed at J7 so as to put the power switch and LED at an alternate location.  (This was not an original 1090XL feature.)  In theory, this board should be able to be dropped into an existing 1090XL chassis.  Realistically, this board is not a perfect reproduction.  Instead, it's an upgraded board that while being fully compatible with legacy 1090XL boards also includes the ability for newer cards, such as the Firmware Board, to take control of newer 1090 card memory regions similar to how the /EXTSEL signal is on the PBI.  i.e.  If programmed to do so, the firmware board can disable a region of RAM on a new 1090 memory card so as to act as a cartridge.  Another upgrade is that this board allows for an XE compatibility card to be installed that supplies the missing /EXTENB signal.

 

 

Bare board:

 

 

Board with 320k and CX85 numeric keypad card installed:

Edited April 19, 2023 by reifsnyderb

[reifsnyderb]

The first picture looks like a massive memory failure.  What you are really seeing is my 600XL downgraded to having OS R. 2/BASIC B internally.  Installed in an attached 1091XL is a firmware board with OS 6.01 installed and Altirra BASIC 1.58.  The memory shows failures because a 16k bank of ROM, that contains the OS 6.01, is banked into the banking region so as to run the Self Test.  BASIC B is shown because the Self Test only displays the BASIC revision accessible through PORTB.  (I should probably change that if a firmware board is configured as such and installed.)

 

What is happening here is as follows:

 

1.  OS R 2 boots and finds the firmware board on the 1091XL.

2.  Control is passed to the firmware board.

3.  The firmware board then ...

     A.  Places a flag in memory for OS 6.01.  (This tells the OS it's RAM based with a firmware board.)

     B.  Disables the OS ROM (and interrupts, etc.)

     C.  Banks in the 16k OS bank from $4000-$7FFF

     D.  Copies OS 6.01 to the RAM in the $C000-$FFFF region

     E.  Calls a special vector in OS 6.01 to essentially do a cold start while staying in RAM.

4.  Altirra BASIC 1.58 is also loaded on the firmware board and nicely loads.    🙂

 

As an added bonus, if I boot the system with the SELECT key down, the 16k version of PacMan loads off of the firmware board.  (This is the version with cut scenes.   🙂    )

 

Tonight was the first night I had this massive breakthrough with this.  I need to figure out why booting with the Option key is failing for some reason and cartridges aren't working yet.  I can, however, boot into DOS 2.5 and run BASIC programs.  The CX-85 Numeric keypad handler, built in to OS 6.01, works as well.

 

Of course, the obvious incompatibility will be that any program that uses RAM in the ROM region, controlled by PORTB, will fail as OS 6.01 is running in RAM.

 

This does, however, show some of the power of the 1090XL/1091XL with a firmware board.   🙂

 

Edited April 25, 2023 by reifsnyderb

[_The Doctor__]

If you press just the computers reset key with the OS running in ram, does it wipe it out or is it persistent?

Edited April 25, 2023 by _The Doctor__

[reifsnyderb]

11 minutes ago, _The Doctor__ said:

If you press reset with the OS running in ram, does it wipe it out or is it persistent?

Right now, it won't do a warmstart and has to do a coldstart.  Since OS R2 will find and run the firmware board, OS R 6.01 will come right back up.  I would have like to have warmstart capability but pressing the reset key also resets the PIA....and screws up the fact that OS R 2 was disabled.    😞   

 

Of course, if I am looking at this wrong or there is a solution, I would love to have a warmstart capability.

 

I completely admit that due to the incompatibility with any software that uses the RAM, within the ROM region, that this type of configuration of the firmware board may be more of a proof-of-concept than anything. 

Edited April 25, 2023 by reifsnyderb

[_The Doctor__]

The translator disks use the ROM in RAM technique but have some protection and can do warmstarts while staying resident. Some are pretty good at basic rom handling as well.

That would be a place to start, since different carts and pbi devices effectively provide actual ROM functionality I'd lean on, if they're willing, @tf_hh, and possibly @flashjazzcat, @candle as they live in the PBI/CART space quite a bit and would be able to better navigate and answer specific hurdles.

 

some ram os's

 

Edited April 25, 2023 by _The Doctor__

[reifsnyderb]

7 hours ago, _The Doctor__ said:

The translator disks use the ROM in RAM technique but have some protection and can do warmstarts while staying resident. Some are pretty good at basic rom handling as well.

That would be a place to start, since different carts and pbi devices effectively provide actual ROM functionality I'd lean on, if they're willing, @tf_hh, and possibly @flashjazzcat, @candle as they live in the PBI/CART space quite a bit and would be able to better navigate and answer specific hurdles.

 

some ram os's

 

Well, it's good to see that it's possible.  Source code is lacking, though.

[flashjazzcat]

Have a look at Avery's Altirra OS source code. Generally speaking, if you need an example of something, look at his code.

 

[reifsnyderb]

19 minutes ago, flashjazzcat said:

Have a look at Avery's Altirra OS source code. Generally speaking, if you need an example of something, look at his code.

 

I'll take a look.  I wasn't sure if a warm start was possible as the Reset button is part of the reset circuitry with goes to not only the processor but the PIA chip as well.  So, my thought is that pressing Reset will also reset the PIA chip...and disable the RAM at $C000+.  Once reset, the processor is now going to run the ROM based OS and it's "game over".  Quite frankly, I am still not convinced a warm start would be possible. 

 

It's also quite difficult to debug this sort of thing.  Presently, I can only emulate so much via Altirra.  On hardware, I need to have a way to get some sort of indication as to why something happened.  So, I've seen plenty of system crashes with no indication as to what happened.  I was using a meter to determine if the $C000+ bank was still set.  Debugging individual sections of the process is possible to some extent.  Putting everything together, to see if it works, is where it becomes very tedious.

Edited April 25, 2023 by reifsnyderb

[flashjazzcat]

19 hours ago, reifsnyderb said:

Once reset, the processor is now going to run the ROM based OS and it's "game over".  Quite frankly, I am still not convinced a warm start would be possible. 

The salient point is that whatever you previously placed in RAM under the OS ROM is still there, so you just need to disable the ROM again.

19 hours ago, reifsnyderb said:

It's also quite difficult to debug this sort of thing.  Presently, I can only emulate so much via Altirra.

Since I assume the hardware works with a stock OS, it might be easier to focus on debugging the hardware using a stock OS and the custom OS using emulated stock hardware for the time being. Altirra certainly provides everything you could need to debug the warmstart issue, although it's necessary to become reasonably conversant with the debugger.

[reifsnyderb]

3 hours ago, flashjazzcat said:

The salient point is that whatever you previously placed in RAM under the OS ROM is still there, so you just need to disable the ROM again.

Here's the problem:  On reset, PIA gets reset (at least as per the 6520 datasheet) so OS R 2 takes over.  There's no way, with a ROM based OS R 2, to change the reset vector.  So it will take until the PBI is scanned, and the firmware board Init code is executed, until anything can be done.  By then, the OS region of the memory has been cleared by OS R 2.  I am guessing I am missing something so I'd love to see how reset was handled. 

3 hours ago, flashjazzcat said:

Since I assume the hardware works with a stock OS, it might be easier to focus on debugging the hardware using a stock OS and the custom OS using emulated stock hardware for the time being. Altirra certainly provides everything you could need to debug the warmstart issue, although it's necessary to become reasonably conversant with the debugger.

I have some debugging code sitting in OS 6.01 to use to debug within Altirra.  This allows me to load OS 6.01 into "RAM", on Altirra, and use the debugger.  On real hardware, I was putting test code on the firmware board that pulled some locations from the $C000+ RAM and placed it in page 6.  Then, as long as I could get into BASIC, I could PEEK the values out of page 6 to confirm the code is running correctly.  The trick is to put both elements together, on real hardware, and have it work.

[flashjazzcat]

2 minutes ago, reifsnyderb said:

There's no way, with a ROM based OS R 2, to change the reset vector.

No, but you have the disk/cassette boot vectors, which are the usual means of trapping reset. That said, I must admit I've slightly lost track of exactly what the objective is. A PBI device would conceivably be able to supplant the computer's OS with a ROM-based replacement, but apologies if that completely misses the point. If your custom OS is in any way mandatory for full exploitation of the PBI device's capabilities, perhaps overriding the machine's OS with an external ROM would be a good way to proceed, but having said that, if you're creating a PBI device with its own BIOS which gets mapped into the math-pack space by the PBI device selection bit, most features can be integrated into the stock OS via the existing New Device mechanism anyway.

5 minutes ago, reifsnyderb said:

I have some debugging code sitting in OS 6.01 to use to debug within Altirra.

Right - I understand. Perhaps an XEX loader module which puts the OS into the Shadow RAM would make life easier.

[reifsnyderb]

6 minutes ago, flashjazzcat said:

No, but you have the disk/cassette boot vectors, which are the usual means of trapping reset.

After checking with the OS source, it may be better to figure out how to trap the reset from the parallel device as the parallel device initialization is prior to the handling of the disk/cassette boot vectors.  This will require a different approach to how I am patching OS 6 to optionally run as a RAM-based OS.

6 minutes ago, flashjazzcat said:

That said, I must admit I've slightly lost track of exactly what the objective is.

The objective is to upgrade the OS to OS 6 via a 1090 card.  (Also BASIC and the floating point pack get upgraded as well.)

6 minutes ago, flashjazzcat said:

A PBI device would conceivably be able to supplant the computer's OS with a ROM-based replacement, but apologies if that completely misses the point. If your custom OS is in any way mandatory for full exploitation of the PBI device's capabilities, perhaps overriding the machine's OS with an external ROM would be a good way to proceed, but having said that, if you're creating a PBI device with its own BIOS which gets mapped into the math-pack space by the PBI device selection bit, most features can be integrated into the stock OS via the existing New Device mechanism anyway.

The custom OS isn't necessary to use the PBI device's capabilities.

 

The 1090XL doesn't permit the computer's ROM to be swapped out as it doesn't permit Refresh to be shorted to ground....thereby disabling the MMU.  So the other option is to have a 1090XL board that installs a RAM-based OS.

 

Some upgrades can't be done, via the PBI, without breaking the interface with other cards.  For example, it is possible to upgrade the math pack from the PBI.  However, you have to put a permanent hold on the /MPD signal and this will cause a conflict with other cards.  (I did this just to confirm it will work.   🙂   )

6 minutes ago, flashjazzcat said:

Right - I understand. Perhaps an XEX loader module which puts the OS into the Shadow RAM would make life easier.

I have a ROM to RAM copy routine that, for debugging purposes, copies the OS to RAM when I call a special vector I added for the OS to be running in RAM.  (I'll probably remove this vector once I get everything working since I initially thought it had to do more than it's doing.)  The ROM to RAM code can be set to not be compiled as per a .define.

 

 

 

 

[flashjazzcat]

Ah - I see. RAM-based operating systems generally suck in terms of software compatibility, unfortunately.

[reifsnyderb]

Just now, flashjazzcat said:

Ah - I see. RAM-based operating systems generally suck in terms of software compatibility, unfortunately.

Yes.  That is a concern of mine.  It won't work with any software that wants to use the same RAM in the C000+ region.

[flashjazzcat]

TBXL, SpartaDOS 3.x, The Last Word, many games and demos, etc, are also out as is anything that manipulates extended RAM without carefully restoring bit 0 of PORTB.

[reifsnyderb]

50 minutes ago, flashjazzcat said:

TBXL, SpartaDOS 3.x, The Last Word, many games and demos, etc, are also out as is anything that manipulates extended RAM without carefully restoring bit 0 of PORTB.

Absolutely.  Previously, I mentioned:  "I completely admit that due to the incompatibility with any software that uses the RAM, within the ROM region, that this type of configuration of the firmware board may be more of a proof-of-concept than anything."

 

When my 800XL was my primary, and only, computer I would have really liked to be able to upgrade the OS in such a fashion.  Having a faster system (with a faster floating point math pack), an improved version of BASIC, and some OS improvements would have been cool.  Being able to plug in a card to do this would have been awesome.  That all being said, I have spent a lot more time figuring out how to do this than expected.

 

Edit to add:  Advanced users will probably upgrade the ROMs and avoid most incompatibilities.

Edited April 26, 2023 by reifsnyderb

[flashjazzcat]

1 hour ago, reifsnyderb said:

Previously, I mentioned:  "I completely admit that due to the incompatibility with any software that uses the RAM, within the ROM region, that this type of configuration of the firmware board may be more of a proof-of-concept than anything."

Yep: definitely haven't read the whole thread.

 

Sounds like a custom OS is just a 'nice to have' extra that's totally optional anyway, although the fact the 1090XL can't completely replace the RAM and ROM on the system seems to me an unfortunately limitation which will clobber any chance of various popular stand-alone devices appearing as add-in cards in one form or another.

[reifsnyderb]

30 minutes ago, flashjazzcat said:

Yep: definitely haven't read the whole thread.

 

Sounds like a custom OS is just a 'nice to have' extra that's totally optional anyway, although the fact the 1090XL can't completely replace the RAM and ROM on the system seems to me an unfortunately limitation which will clobber any chance of various popular stand-alone devices appearing as add-in cards in one form or another.

The 1090XL can completely replace the RAM on a system and still has a huge amount of capability.  All of the following, and more, are possible:

 

80 column cards (working)

Memory cards.  (i.e.  320k PORTB RAM (working), 4MB Axlon compatible)

Other video cards

SD card "disk drives"

Parallel FujiNet cards

CX-85 numeric keypad interface (working)

Print Spooler

80 column firmware-based card

OS Add-on cards  (i.e.  Fast SIO)

CPU cards (i.e.  Z-80)

Sound cards

etc., etc.

 

The main thing the 1090XL doesn't allow is to ground the Refresh line to shut down the MMU.  (This is how the ROM has been "swapped out" by others on the PBI.)  I didn't add that capability to the XE compatible 1090XL as I didn't think it would be something Atari would do.  (It also shorts out ANTIC' refresh line.)  That being said, the capability could be added and a "modernized" 1090XL would be able to completely replace the ROM.  I just won't do it on my system as I really don't care how safe it's deemed to be to short out ANTIC's refresh; I simply don't like the idea of doing something like that to an irreplaceable 40 year old chip.  If ANTIC FPGA replacements become available, and support this, it's a different situation entirely.

 

I've put together documentation, and released it, to help take the mystery out of the PBI (and 1090XL) in the hopes other hardware developers will start creating boards for the 1090XL.

 

 

 

 

Edited April 26, 2023 by reifsnyderb

[flashjazzcat]

Well, if it can replace all the system RAM (which it obviously must be able to do, now that I think about it), that's very useful indeed. It just struck me as unfortunate that you can't replace the OS ROM with an external one, since you're expending a reasonable amount of time and effort trying to get your custom OS to launch and install from the 1090XL. But clearly the device remains very versatile while remaining faithful to Atari's original design.

Edited April 26, 2023 by flashjazzcat