1090XL remake

[_The Doctor__]

You can limit current with any pull down though, what happens when MPD, ANTIC DMA is off, etc.

You mention holding MPD affects other cards? What cards and from when?

The 1090 was in development, there were about 3 different iterations, I am certain that Atari was not only thinking about adding normal items like ram,storage,math pack/co processing and display as well as CPM, but Atari was also trying to restore the ability to swap out the personality just like in the 800 line. I wouldn't be afraid of adding anything to the 1090... even ATARI deleted some components on the 1090 PCB that could optionally be put back (some folks are like why is this here it doesn't connect to anything really-but it could- it was just isolated until it would either be used or fully deleted depending on how it fleshed out). The buffer is in the BOX or on the cable (Julia cable etc). See that was all in flux and depended on discovery. You are picking up on that discovery phase but then wresting with it as it was the final product. The is no reason anyone can't solve or modify what is so that all of it can still work. I commend your work, you shouldn't have to twist your mind to the pain over some of it though. Who says you can't have switchable opto isolation or other connect disconnect schemes? You really have quite a chance to break ground here, and I am excited to see what that becomes.

[reifsnyderb]

52 minutes ago, _The Doctor__ said:

You can limit current with any pull down though, what happens when MPD, ANTIC DMA is off, etc.

No idea.  Are you suggesting that maybe if ANTIC DMA were to be turned off that this would be a better situation?

52 minutes ago, _The Doctor__ said:

You mention holding MPD affects other cards? What cards and from when?

The PBI cards use the /MPD to disable the math pack region and bank in 2k of ROM.  All 1090 cards, that have firmware to auto-execute, follow the 1090 protocol as $D800-$DFFF is the only initial location firmware can be executed from.  So if you hold down the /MPD line you can only use one card as no other card can then use the $D800-$DFFF region for anything else.  As a hack, you can use this feature, for one card, to install a new math pack as opposed to 1090 card firmware.

52 minutes ago, _The Doctor__ said:

The 1090 was in development, there were about 3 different iterations, I am certain that Atari was not only thinking about adding normal items like ram,storage,math pack/co processing and display as well as CPM, but Atari was also trying to restore the ability to swap out the personality just like in the 800 line. I wouldn't be afraid of adding anything to the 1090... even ATARI deleted some components on the 1090 PCB that could optionally be put back (some folks are like why is this here it doesn't connect to anything really-but it could- it was just isolated until it would either be used or fully deleted depending on how it fleshed out). The buffer is in the BOX or on the cable (Julia cable etc). See that was all in flux and depended on discovery. You are picking up on that discovery phase but then wresting with it as it was the final product. The is no reason anyone can't solve or modify what is so that all of it can still work. I commend your work, you shouldn't have to twist your mind to the pain over some of it though. Who says you can't have switchable opto isolation or other connect disconnect schemes? You really have quite a chance to break ground here, and I am excited to see what that becomes.

The 1090XL board, that was finally created by Atari, matches the 3rd iteration.  The 1090XL remake board works as per Atari's 3rd iteration of the 1090XL.

 

Well, I have added and/or changed a few things to the 1090XL (and 1091) boards. 

1.  PBI pin 33 can be connected to the /HALT line.  The "new" 1090XL boards have a pin for this line.

2.  The XE has some connections, such as RD4 and RD5, that are now passed into the 1090XL board.  These are used for the XE compatibility card that will re-create the /EXTENB signal that the XE is missing.

3.  I swapped out one of the transceivers for a ATF16V8B PLC and programmed it to act as a transceiver.  This permits the XE compatibility card to shut down the /EXTENB input automatically in a plug-and-play fashion.

4.  I also researched all known cards to ensure that my changes did not break any compatibility with any legacy cards.

5.  I set aside a line, on the 1090 bus, to act as a RAM disable line.  If a 1090 RAM card is designed to handle this, it's RAM can be shutdown by another card.  This gives the firmware card the ability to both shutdown the computer's memory (via /EXTSEL) and any RAM cards located on the 1090 bus.  In the case of the firmware card, it allows the firmware card to bank ROM in anywhere that doesn't conflict with the computer's ROM.  This signal line could also be used to add Axlon compatible memory, to the 1090, while still working with other memory on the 1090 bus.

6.  There are some lines that I repurposed as no other 1090 card used them.  i.e.  /RDY and /Refresh

 

The newest 1091 has all of these changes.

 

For those who want to "abuse" the /Refresh line, I could easily make the next revision have a slot set aside with the /Refresh line connected.  There would be a tradeoff, however, in that some cards would not be able to use that slot for other purposes.  I believe that Atari wanted the user to be able to plug a card into any slot as they would all be electrically identical.  I suppose that this feature could have a jumper on it or a ATF16V8B attached, in some way, so as to make it more user friendly.

 

I just realized that it's probably possible to remove the open collector /MPD line, on the firmware board so it could use the /MPD signal or listen to the /MPD signal as necessary.  This should greatly simplify swapping out the OS.  Of course, if some software enabled the original OS, on the system board, there would be some bus contention.

 

Best Regards,

 

Brian

 

 

 

 

 

 

 

[_The Doctor__]

20 minutes ago, reifsnyderb said:

I just realized that it's probably possible to remove the open collector /MPD line, on the firmware board so it could use the /MPD signal or listen to the /MPD signal as necessary.  This should greatly simplify swapping out the OS.

Yes! Sounds like a plan.

 

1090 cards and bus used as an intelligent devices.

Edited April 26, 2023 by _The Doctor__

[reifsnyderb]

3 hours ago, _The Doctor__ said:

Yes! Sounds like a plan.

 

1090 cards and bus used as an intelligent devices.

The next version of the firmware board will have this.  In KiCad, I just modified the firmware board design and connected /MPD directly to the ATF16V8B.  It will now be able to be used as in input or output.   🙂

 

I should have done that before....

Edited April 27, 2023 by reifsnyderb

[drac030]

3 hours ago, reifsnyderb said:

As a hack, you can use this feature, for one card, to install a new math pack as opposed to 1090 card firmware.

I do not quite get it: if external hardware can map-in own ROMs at $d800-$dfff, when a non-zero value is written to $d1ff, why it cannot map own math-pack when a zero is written to $d1ff?

 

Of course, it has to be done in a clever way to avoid OS checksum failure during reset. So, maybe: 1) unmap external ROMs on Reset, 2) on the first non-zero write to $d1ff activate the math-pack mapping on $d1ff=$00. Am I missing something?

 

Of course, a software reset would still be a problem, but you are patching the OS anyways, so you probably already have incorporated zeroing $d1ff into the procedure that zeroes all other I/O.

[reifsnyderb]

33 minutes ago, drac030 said:

I do not quite get it: if external hardware can map-in own ROMs at $d800-$dfff, when a non-zero value is written to $d1ff, why it cannot map own math-pack when a zero is written to $d1ff?

$D1FF (PDVS) is the select register for the parallel device.  Each parallel device may have this register as this register does not exist on the computer.  Depending on the parallel device, if $D1FF is set to zero, the device is either disabled or some of the devices registers can be disabled.  Realistically, it depends upon the device.  For some devices, Atari reserved addresses for the device to be active all the time.  To enable a device, that has this register, $D1FF has a bit set that coincides with the device ID set on the card.  (Device 0-7)

 

That being said, the firmware board would start up in a disabled state.  The math pack would not be active.  The OS, upon scanning the parallel devices, by setting each individual bit of $D1FF to on and checking for a couple ID bytes, would find the firmware board and run it's program.  This program would then enable the math pack by setting the correct bit at $D100 to zero.  Then, the program returns to the OS.  This all happens after the OS does it's ROM checksum.

 

The next version of the firmware board will be able to map it's own math-pack when a parallel device is "turned off" by setting $D1FF to 0.  I am trying to run the OS in RAM with this version of the firmware board.  I'll have to hack the board to get it working like the next version of the firmware board.

33 minutes ago, drac030 said:

 

Of course, it has to be done in a clever way to avoid OS checksum failure during reset. So, maybe: 1) unmap external ROMs on Reset, 2) on the first non-zero write to $d1ff activate the math-pack mapping on $d1ff=$00. Am I missing something?

See above.

33 minutes ago, drac030 said:

 

Of course, a software reset would still be a problem, but you are patching the OS anyways, so you probably already have incorporated zeroing $d1ff into the procedure that zeroes all other I/O.

I may be wrong, but I think the problem with any warm start scenario is that the reset line also resets the PIA.  So bit zero of PORTB would be reset to 1.  With an OS in RAM, the OS is there but inaccessible.  With the OS sitting in a mapped ROM, on the firmware board, I can envision there would be bus contention as both the OS ROM and the firmware board ROM would be responding to the same address.  Maybe I should add the capability, to the firmware board, to process a reset?  (I am actually out of inputs for the ATF16V8B.  However, a compromise solution or an added solder jumper would allow for this.

 

Best Regards,

 

Brian

 

EDIT to add:  Processing a reset signal may require some serious changes...

 

Edited April 27, 2023 by reifsnyderb

[reifsnyderb]

I found a solution to upgrading the OS ROM from a 1090XL.  🙂

 

Running the OS in RAM would have probably worked.  However, it was becoming a case of whack-a-mole to get it to work.  I'd fix one problem then find 2 more.  The last problem I fixed was I couldn't get the OS to run without BASIC.  Upon investigation, I discovered Atari determined the available memory by stopping when it could no longer write to the memory.  So, it required a ROM to act as a "stop point" when checking the maximum available memory.  If the OS is in RAM, it happily writes into the OS and device region while looking for the end of memory.  This required another patch to limit the upper search range to A0.  Then it finally ran without BASIC.  Upon further testing, Donkey Kong wouldn't run at all and M.U.L.E. crashed.  As you can probably figure, M.U.L.E. crashing was the final straw. 

 

So, I re-grouped and decided to keep the OS on the ROM chip on the firmware board.

 

I had to modify the firmware board so that it could also listen to the /MPD signal.  That required removing the open-collector buffer from the /MPD signal and programming the firmware board MMU such that the /MPD was now an I/O signal.  The next modification was I needed to have the A11 signal running into the firmware board MMU so that it could determine if the CPU was working with the device region or not.  After those two modifications, and reprogramming all the chips on the modified firmware board, it worked!  I can now upgrade the OS and BASIC from the 1090.  🙂    There are a couple caveats, of course.  One is that you can't bank in the new OS self test because I don't have enough data line inputs to the firmware board MMU.  The other is that any software that attempts to enable the computer's native OS and/or BASIC via PORTB will crash the system.  As a work-around, I programmed the firmware board's ROM to so that the computer's internal OS and BASIC are used if the computer is booted with the Select key held down.

 

Other than the two issues, above, I need to figure out why the Shift/Control/Delete cold start isn't working yet.  I think this can be resolved.

 

So, now the ROM upgrade is working as follows:

1.  Upon boot, run the firmware board ROM.

2.  If Select is held down, abort and use the native OS ROM.

3.  Set the firmware OS flag.

4.  Disable the native OS.

5.  Enable the firmware board OS on the 1090XL.

6.  Jump to the Reset vector to start the firmware board's OS.

 

Here are the two PLD files for the firmware board.  The decoder chip decodes $D1FF, $D100, the $D1xx range, and $Dxxx.  The MMU chip does the "heavy lifting" and handles all of the firmware board's memory management.  Between these chips, and the ROM chip, this board can be re-configured to do a lot of things.

 

I should probably write up a guide as to how to use this board.   🙂

 

 

1090 Firmware Board Decoder.PLD

1090_FIRMWARE_BOARD_MMU_OB.PLD

 

Here's the wiring of the two logic chips on the firmware board....

 

 

The front of the firmware board, with changes...

 

 

Here's the back of the new firmware board design:

 

The solder jumpers are as follows:

1.  1090 RD -- 1090 RAM disable.  Jumper only with newer 1090/1 XL/XE boards.  This allows the board to disable the RAM on other boards on the 1090 bus only.

2.  A17/A18 -- Normally a SST39SF010 flash ROM chip is used.  If not available, get a bigger chip and solder these jumpers as appropriate.

3.  A12/A11/D2 --   Firmware board MMU pin 6 input.  Solder only connection if and as needed for the application.

 

 

 

I need to order some more Mega 4 boards (4MB Atari 800 RAM boards) this week and will throw these in with the order.   🙂

 

 

 

Edited April 29, 2023 by reifsnyderb

[+Larry]

Would a USB 1.1 card be feasible for the 1090?  That could allow "modern" 3.5" USB floppy drives to be easily connected.

 

Related: Was anyone successful in getting a ABBUC USB cartridge (sold in the U.S. by Atarimax) working with anything?  I had one of those carts  (and don't think I still have it), but I was never able to get any USB thumb drive to work with it.  I remember that it had been tested with some brands that I never heard about in the U.S.

[reifsnyderb]

33 minutes ago, Larry said:

Would a USB 1.1 card be feasible for the 1090?  That could allow "modern" 3.5" USB floppy drives to be easily connected.

I think a 1090 interfaced with a Raspberry Pi Pico would work.

[+x=usr(1536)]

45 minutes ago, reifsnyderb said:

I think a 1090 interfaced with a Raspberry Pi Pico would work.

Apologies if I missed this elsewhere in the thread, but how does addressing the various cards on the 1090 work?

 

I'm thinking that this might be an interesting way to build offload processing - or, potentially, SMP.

[reifsnyderb]

1 hour ago, x=usr(1536) said:

Apologies if I missed this elsewhere in the thread, but how does addressing the various cards on the 1090 work?

 

I'm thinking that this might be an interesting way to build offload processing - or, potentially, SMP.

The short answer is that since the 1090 card has access to the entire parallel bus it can take over most addresses, with few exceptions.  One exception being that the 1090 cannot disable the computer's MMU.  This is how a 1090 can supply RAM upgrades.

 

The next shortest answer is that the 1090 cards can have a device id and a ROM.  On boot-up, the XL OS attempts to enable a card by trying each possible device id at $D1FF.  If two bytes, in the $D8xx range, match what is expected then the XL OS runs the code on the ROM on the card.  (The 1090 card will disable the math pack so there isn't a conflict.)  Once a card is "enabled" by selecting it's device ID, the card can make address registers available in the $D1xx range available for use.  Also, addresses within the region of $D600-$D7FF are supposed to be set aside for parallel device use.  (This can now conflict with a VBXE, if installed.)  Since the 1090 cards can take over the region of $D8xx-$DFFF, it's also possible to use some of that region as device registers or RAM.  Since a 1090 card has access to the entire parallel bus, it can also take over any other address range, with few exceptions.  Everything is optional.  Atari also has some D1xx addresses reserved for certain 1090 functions.  It's possible to have the 1090 card simply respond to an address without any concern as to the device ID as well.

 

The much longer answer is here:

Parallel Port Guide v0_92.pdf

 

Best Regards,

 

Brian

 

 

Edit to add:  Parallel port devices can also register and create an IRQ.  When such IRQ is called, the OS can run a handler located on the parallel port device's ROM.

 

 

Edited May 1, 2023 by reifsnyderb

[+Allan]

1 hour ago, Larry said:

Would a USB 1.1 card be feasible for the 1090?  That could allow "modern" 3.5" USB floppy drives to be easily connected.

 

Related: Was anyone successful in getting a ABBUC USB cartridge (sold in the U.S. by Atarimax) working with anything?  I had one of those carts  (and don't think I still have it), but I was never able to get any USB thumb drive to work with it.  I remember that it had been tested with some brands that I never heard about in the U.S.

The problem was/is that there wasn't enough people creating drivers for this. There was some work done with getting some controllers to work with it but it petered out after a while. The hardware was the there but it needed more dedicated people to get the cart to work with more USB devices, especially storage devices. There is no reason why someone couldn't pick this up today,luckily.  But again, it requires someone that has the knowledge, time and drive to do it, with the understanding that they won't get much back for it other than people's appreciation.

 

We have a small number of people doing things like this but not enough. Hopefully more people  will get involved.

 

[reifsnyderb]

21 minutes ago, Allan said:

We have a small number of people doing things like this but not enough. Hopefully more people  will get involved.

This is a big reason why I put together the Parallel Port Guide.  I am (was?) hoping that by putting everything I've discovered into one document that it would make it a lot easier to construct parallel port devices.  My research into developing parallel port cards was complicated by the fact that some of the "official" sources are wrong.  Because of this wrong information, I designed test boards that depended upon bad information that had never been corrected.  (See below)  I corrected that information and released it.  Some other information, on Atari parallel port interfaces was so watered down so as to be almost useless.  Mapping the Atari has wrong information, etc.

 

I've been thinking about re-organizing the Parallel Port Guide document into more of a datasheet type format.  I haven't decided yet.

 

 

 

One piece of wrong information I discovered:

 

Antic Vol. 3 No. 10 - February 1985 - Money Mastery – Toolbox

Parallel Bus Revealed: Part 2, Earl Rice

 

EXTENB does not enable the external hardware as described. If EXTENB is high, the external hardware is signaled that the computer is accessing the RAM. For example, EXTENB is not set high if an address in D1xx is called.

 

This error resulted in my mistaken belief that EXTENB would be set high if an address in the D1xx range was called.  Building a board, based upon this article, resulted in a massive fail.

 

 

 

Edited May 1, 2023 by reifsnyderb

[_The Doctor__]

2 hours ago, reifsnyderb said:

This is a big reason why I put together the Parallel Port Guide.  I am (was?) hoping that by putting everything I've discovered into one document that it would make it a lot easier to construct parallel port devices.  My research into developing parallel port cards was complicated by the fact that some of the "official" sources are wrong.  Because of this wrong information, I designed test boards that depended upon bad information that had never been corrected.  (See below)  I corrected that information and released it.  Some other information, on Atari parallel port interfaces was so watered down so as to be almost useless.  Mapping the Atari has wrong information, etc.

 

I've been thinking about re-organizing the Parallel Port Guide document into more of a datasheet type format.  I haven't decided yet.

 

 

 

One piece of wrong information I discovered:

 

Antic Vol. 3 No. 10 - February 1985 - Money Mastery – Toolbox

Parallel Bus Revealed: Part 2, Earl Rice

 

EXTENB does not enable the external hardware as described. If EXTENB is high, the external hardware is signaled that the computer is accessing the RAM. For example, EXTENB is not set high if an address in D1xx is called.

 

This error resulted in my mistaken belief that EXTENB would be set high if an address in the D1xx range was called.  Building a board, based upon this article, resulted in a massive fail.

 

 

 

It was a work in progress so it'll improve with discoveries for certain, the more hands on it, the better it will get. It all needs to be documented as it progresses. Some of our new assumptions will be tested as well.

Edited May 1, 2023 by _The Doctor__

[Nolium]

I'm building 1066 (64KB memory expansion) and I have a problem with U20 (IC?). Anyone knows what is it?

 

U20 -- Conn_02x08_Counter_Clockwise

[kenames99]

you can leave that blank and the 64K will work. atari had future plans I guess but clausb stepped in and filled in the blank. he posted a schematic that populated that location and then swap the ram for 256K chips and you have a 256K ram board. I never tested that tho but will sometime in the future.

 

Ken

 

 

 

[Nolium]

40 minutes ago, kenames99 said:

you can leave that blank and the 64K will work. atari had future plans I guess but clausb stepped in and filled in the blank. he posted a schematic that populated that location and then swap the ram for 256K chips and you have a 256K ram board. I never tested that tho but will sometime in the future.

 

Ken

 

 

 

Thanks!

[Nolium]

Jumper J1 (CARD1/CARD2), what is its function?

Switch (Bank switch mode), what kind of switch is suggested and what purpose does it serve?

U23 (EP8212) is this a delay line chip? https://www.ebay.com/itm/125803129826?hash=item1d4a736be2:g:B-IAAOSwNgVgqpJl&amdata=enc%3AAQAIAAAA0EZRj1jZAgDGPVcAIwtTxEbbc9RRxK%2BU28LPC1anp%2BfT7qLsF5tqbGINwLK0d%2F5eWaCC1bCTAZVfhhoKGqPnPPmtTFdY7rcgdOplcrA2JK0M30OWczScohstfuwlXUf3BRqliDByLGXgDW5PafOpZWMyrXpznKlOfpnTvVMatd%2BQwnS9vX8YFdZPBZN71j77RCWTEiKkJPkIgnGFIj1hmU26f2aA0NnoGmQ8i9kd9URYMhYKLq2GHz%2BgOx4ifdhgSZqN4UCUi3qSEkfqhqz7BTw%3D|tkp%3ABk9SR5zN37L8YQ

[reifsnyderb]

35 minutes ago, Nolium said:

Jumper J1 (CARD1/CARD2), what is its function?

Switch (Bank switch mode), what kind of switch is suggested and what purpose does it serve?

U23 (EP8212) is this a delay line chip? https://www.ebay.com/itm/125803129826?hash=item1d4a736be2:g:B-IAAOSwNgVgqpJl&amdata=enc%3AAQAIAAAA0EZRj1jZAgDGPVcAIwtTxEbbc9RRxK%2BU28LPC1anp%2BfT7qLsF5tqbGINwLK0d%2F5eWaCC1bCTAZVfhhoKGqPnPPmtTFdY7rcgdOplcrA2JK0M30OWczScohstfuwlXUf3BRqliDByLGXgDW5PafOpZWMyrXpznKlOfpnTvVMatd%2BQwnS9vX8YFdZPBZN71j77RCWTEiKkJPkIgnGFIj1hmU26f2aA0NnoGmQ8i9kd9URYMhYKLq2GHz%2BgOx4ifdhgSZqN4UCUi3qSEkfqhqz7BTw%3D|tkp%3ABk9SR5zN37L8YQ

Here's the manual for that card:

 

1090_64K_ram_card_owners_guide.pdf

 

 

[Nolium]

2 minutes ago, reifsnyderb said:

Here's the manual for that card:

 

1090_64K_ram_card_owners_guide.pdf 723.21 kB · 1 download

 

 

Thanks!

[reifsnyderb]

44 minutes ago, Nolium said:

Jumper J1 (CARD1/CARD2), what is its function?

Switch (Bank switch mode), what kind of switch is suggested and what purpose does it serve?

U23 (EP8212) is this a delay line chip? https://www.ebay.com/itm/125803129826?hash=item1d4a736be2:g:B-IAAOSwNgVgqpJl&amdata=enc%3AAQAIAAAA0EZRj1jZAgDGPVcAIwtTxEbbc9RRxK%2BU28LPC1anp%2BfT7qLsF5tqbGINwLK0d%2F5eWaCC1bCTAZVfhhoKGqPnPPmtTFdY7rcgdOplcrA2JK0M30OWczScohstfuwlXUf3BRqliDByLGXgDW5PafOpZWMyrXpznKlOfpnTvVMatd%2BQwnS9vX8YFdZPBZN71j77RCWTEiKkJPkIgnGFIj1hmU26f2aA0NnoGmQ8i9kd9URYMhYKLq2GHz%2BgOx4ifdhgSZqN4UCUi3qSEkfqhqz7BTw%3D|tkp%3ABk9SR5zN37L8YQ

I just looked up the schematic of the 800XL and 1066 card's U23.  The pinout to that delay line is identical to that of an 800XL.  So a 600XL/800XL delay line, or modern equivalent, should work.

Edited May 3, 2023 by reifsnyderb

[Nolium]

5 minutes ago, reifsnyderb said:

I just looked up the schematic of the 800XL and 1066 card's U23.  The pinout to that delay line is identical to that of an 800XL.  So a 600XL/800XL delay line, or modern equivalent, should work.

Awesome, thanks!

[reifsnyderb]

8 hours ago, kenames99 said:

you can leave that blank and the 64K will work. atari had future plans I guess but clausb stepped in and filled in the blank. he posted a schematic that populated that location and then swap the ram for 256K chips and you have a 256K ram board. I never tested that tho but will sometime in the future.

 

Ken

 

 

 

I just found the schematic.  It looks like @ClausB dropped in a 74LS153 and grounded pin 1.  This makes sense and I believe would extend the bank selection capability at $D1FE.  It's almost as though Atari was thinking the same thing but forgot to ground out pin 1.  Also, there would be some sort of banking possible through the 40 pin connector, at the top, as well.  It probably wouldn't hurt to ground out pin 1 to add that option, anyhow, while keeping the original design for reference.

 

 

 

[Nolium]

4 hours ago, reifsnyderb said:

I just found the schematic.  It looks like @ClausB dropped in a 74LS153 and grounded pin 1.  This makes sense and I believe would extend the bank selection capability at $D1FE.  It's almost as though Atari was thinking the same thing but forgot to ground out pin 1.  Also, there would be some sort of banking possible through the 40 pin connector, at the top, as well.  It probably wouldn't hurt to ground out pin 1 to add that option, anyhow, while keeping the original design for reference.

 

 

 

Thanks, 74LS153 added to order.

[Nolium]

I guess my 64KB card is working. Tested with 800XLF.