CPM/Z-80 card for the 1090XL -- Calling anyone with Z-80 experience!

[Overange]

6 hours ago, adam242 said:

 

Sorry for going off-topic, but what is that pastel-button unit to the right of the 1090 in the first pic?

Atari Miria

 

 

 

[+DjayBee]

2 hours ago, Overange said:

Atari Miria

 

 

WOW, never heard of this one.

[+kheller2]

No love for the 1200XLS.  

[reifsnyderb]

1 hour ago, kheller2 said:

No love for the 1200XLS.  

I'd love it if the 1200XLs had a PBI.  I recently bought a 1200XL and repaired it.  I might finally have a theory as to why the 1200XL didn't have a PBI.  Since the PBI is just an edge connector it really has no cost, so it never made sense as to why it was omitted.  However, while working on my 1200XL it occurred to me that the power supply section took up a lot of space.  My belief, therefore, is that because the power supply section took up so much space there was never any room for a PBI. 

[FifthPlayer]

7 hours ago, Overange said:

Atari Miria

 

 

 

Skip to 6:10 for some actual information (mostly speculation) on the Mirai.  I've never heard of this one either!

Edited March 21 by FifthPlayer

[+kheller2]

3 hours ago, reifsnyderb said:

I'd love it if the 1200XLs had a PBI.  I recently bought a 1200XL and repaired it.  I might finally have a theory as to why the 1200XL didn't have a PBI.  Since the PBI is just an edge connector it really has no cost, so it never made sense as to why it was omitted.  However, while working on my 1200XL it occurred to me that the power supply section took up a lot of space.  My belief, therefore, is that because the power supply section took up so much space there was never any room for a PBI. 

The original 1200/1000 had a bus header and dual intelligent SIO ports. 
 

To make it even more confusing, there were two side by side projects going on at the same time. 

[reifsnyderb]

1 hour ago, kheller2 said:

The original 1200/1000 had a bus header and dual intelligent SIO ports. 
 

To make it even more confusing, there were two side by side projects going on at the same time. 

That all makes sense.  It also makes sense that the 1200XL was subject to cost reductions.  If an external 5vdc power supply wasn't ready yet, it would also explain the power supply situation.

[reifsnyderb]

Work continues on the CP/M card.  Yesterday I received some components in and installed them with the hopes of getting the clock circuit working.  It wasn't to be, unfortunately.  It's also no secret that I am not the greatest with electronics.  So, I may have interpreted the theory on how the circuit works wrong.  One thing I do know is that any latches need to be set before the 6502's Phi2 falls or else the data may be lost.  So I am thinking the whole purpose of this section of the CPM card was to take the buffered Phi2, re-align it, and use it for both the Z-80's clock and the latches. 

 

 

Anyhow, the resulting output, at the emitter, was a square wave that oscillated between 4 to 4.2 volts or so. (The square wave didn't drop to zero volts.)  It was similar to Phi2 and inverted but not shifted as expected.

 

Looking at the pictures, again, I may have mis-interpretted R2 (immediately to the right of the transistor) and it might be 1.2k ohms.  I am not sure.  Either way, this still doesn't look like any R/C circuit I've seen a description of.

 

I played around with the circuit, and changed some components, etc., and eventually got an R/C circuit working but I am not too thrilled about the result.  Given the shape of the wave form, it would have to be re-squared. 

 

If anyone wants to take a look at this and has any ideas, theories, etc., I am open to suggestions.

 

Here's the schematic I came up with and pictures of the board in that location:

 

The transistor, resistor, capacitor, and two resistors are in the same order (from left to right) on both the board and schematic.  It's quite possible the transistor should be a PNP transistor so it would be turned on when Phi2I was negative as opposed to positive.  But, that's rather minor.

 

 

 

 

 

 

 

If I can't figure out a decent fix for this, I am seriously considering taking BPhi2, from the 1090XL, running it through a delay line that is almost identical to that in the 800, and sending it through the inverter so as to both shift and clean-up the signal.  If the delay line is set correctly, the inverter's output should provide a proper clock signal that 50ns (or so) ahead of the CPU's Phi2 signal. 

 

Thanks!

 

 

 

 

 

 

 

 

 

Edited March 23 by reifsnyderb

[kenames99]

the resistor on the right is 22 ohms, not 220. I also think the resistor just to right of transistor is 1.2K ohm. the others look correct. that is all according to my very old eyes. thanks.

 

Ken

 

[sup8pdct]

Here is a schematic i have for the z80 card.

Clock circuit looks somewhat similar but source is completely different

[reifsnyderb]

25 minutes ago, sup8pdct said:

Here is a schematic i have for the z80 card.

Clock circuit looks somewhat similar but source is completely different

 

 

Good catch!  There are some similarities.  Once I dropped a PNP transistor in, the transistor orientation was corrected.  There is a reasonable possibility there's an extra trace under the center resistor and capacitor, too, as the color of the board changes in between them.  Adding an additional connection fixes that and brings both transistor circuits a lot closer. 

 

In the pictures, there isn't any sign of the inverter being connected like that, or at all.  (I just made an educated guess that it had to be connected else there was no place the clock pulse could be coming from.)  The board picture strongly implies that the transistor circuit is triggered by a line coming from the input to an OR gate on the chip below it.  This couldn't be right unless the inverted Phi2 goes to the OR gate input as well.  Given the other connections, that wouldn't make sense, either.  It's just too bad we don't have some pictures of the Z-80 board with the traces on the correct side so as to be able to figure out all the traces.

 

 

 

 

 

 

[reifsnyderb]

Development continues on the CPM card!

 

Given the design, I had serious concerns about the timing and clock signal.  So, I went with my delay line idea and was able to tune the clock so that Phi2 drops about 50ns before the CPU's Phi2 clock signal.  This should ensure there aren't any problems with the 6502 writing to the register on the card.

 

While I didn't bother to setup the voltages, on the scope, when I previously checked the voltages both are over 4 volts at the peak.  This should be fine.  The top trace is Phi2 right off of the 6502 CPU and the bottom trace is the shifted Phi2 signal after it exits the 74LS04 on the CPM card.  This shows the shifted Phi2 signal drops about 50ns before the 6502's Phi2.  I will need to keep an eye on the zero voltage level fluctuations.

 

 

Here's a picture of the front of the board in it's test configuration.  Once I verify the registers are working, I'll install the Z-80 chip.

 

 

Here's the back of the board.  The delay line circuitry is hanging on.  I shamelessly took this circuit from the A800 personality card and adjusted it's timing slightly.

 

 

Finally, here's a rendering of the card with the delay line added:

 

 

 

 

 

 

 

 

 

[reifsnyderb]

More CPM card development!  We have life!

 

 

 

The register control, from the Atari, appears to work.  The card has been configured such that the Z-80 reset is held low, meaning the Z-80 is essentially "off", until a read or write to $D1F0.  During some testing, I had to make a minor change to the board and continued testing.  I was able to confirm the reset control works and I can store data in a register.  Also, I could confirm that when $D1F0 is accessed the clock signal to the net-yet-connected RAM card works as well.  So, I finished assembly.  When the power is turned on, the Z-80 address lines are still dead.  Once $D1F0 is accessed, the Z-80 now comes alive and the scope shows activity on the Z-80 address lines!

 

 

 

[Geister]

Cool!, Now what are they doing for a ROM on that thing?

[reifsnyderb]

42 minutes ago, Geister said:

Cool!, Now what are they doing for a ROM on that thing?

There is no ROM.  The 64k RAM card has a bank-switched option.  The only way they could have loaded CP/M was to use the Atari/host to load, at the very least, a BIOS with a boot loader into the RAM card.  It's also possible the Atari/host loaded the entire CP/M OS onto the RAM card.  Afterwards, the Atari/host would start the Z-80 and be used for I/O only.  When the Z-80 starts, it takes over the 64k RAM card and runs the code on it.

 

If only a boot loader were to be loaded, then a CP/M disk would have to be in an Atari disk drive.  (From what I've been reading, CP/M has a BIOS section that is the only section that has to be customized for the system.  So, this BIOS would be customized to use the Atari as the I/O for the keyboard, screen, printer, and disk drives.)  When the CP/M boot loader would initialize, it would then load CP/M off of an Atari disk.

Edited March 30 by reifsnyderb

[reifsnyderb]

Z-80 Life is confirmed!  We have the ultimate answer!  

 

My "test" 800XL has my 800XL re-make board 1.1a and my OS R6.2 pre-release OS.  This OS has Wozmon, so it's perfect for this sort of testing. 

 

The registers on the Z-80 card, that I used for this test, are as follows:

D1F0 - Start the Z-80 by raising the Z-80 /reset signal, allow the Z-80 to take control of the 64k RAM card, enable the Z-80 transceivers, etc.

D1F1 - Read a byte

D1F3 - Check to see if a byte is available.  (Bit 7 will be set.)

4000-7FFF is the first bank of the 64k RAM card and the Z-80 will see it as 0000-3FFF.

 

I used the following Z-80 code and converted it to Hex:

ld a,$42

out (0),a

halt

 

This resulted in the hex of:  3E,42,D3,00,76

 

So, if the Z-80 works, it should load $42 into it's output register 0.  The Atari should then find this number at $D1F1.

 

So, to interpret the screen, below...

1.  Shift/Control/W to enter Wozmon.  Backslash is now displayed

2.  Find out if a byte is waiting by checking D1F3.  The result is 7F, so no byte is waiting as bit 7 isn't set.

3.  Enter the Z-80 code at $4000:  3E,42,D3,00,76

4.  Start the Z-80 with a call to D1F0

5.  Check D1F3 to see if a byte is waiting.  D1F3 returns FF.  Bit 7 is set!  Something is there.

6.  Check D1F1 to see what byte is in the register.  It is 42!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

 

Below is a screenshot and a picture of the 1090XL with the memory card in front and Z-80 card in the back.

 

             

 

 

 

 

 

 

Edited March 30 by reifsnyderb

[ivop]

Great work! It would be nice if you used the CP/M-65 diskdefs for the disk format once you assemble a new BIOS so it would be easier to exchange data between them. Is anything known about how the Z80 card communicated with the Atari to trigger BIOS functions? If you have any questions, I could possibly be of help as to how to "trap" BIOS calls and what the Atari should do when it is asked to execute a certain BIOS call. Here's an example where I use OUT to trigger an emulator to do the BIOS stuff: https://github.com/ivop/atari8080/tree/main/cpm22 It also shows how to assemble working BIOS, BDOS and CCP files. Currently it includes the atarihd (1MB) diskdefs, but that could also be the 90kB SD version. Instead of a single OUT and RET, you would need some way to communicate the proper registers to the Atari and read them back after the Atari is finished. You could use a small fixed block of high memory for that.

 

Edit: diskdefs: https://github.com/ivop/cpm65/blob/master/diskdefs

 

Edited March 31 by ivop

[reifsnyderb]

3 hours ago, ivop said:

Great work! It would be nice if you used the CP/M-65 diskdefs for the disk format once you assemble a new BIOS so it would be easier to exchange data between them. Is anything known about how the Z80 card communicated with the Atari to trigger BIOS functions? If you have any questions, I could possibly be of help as to how to "trap" BIOS calls and what the Atari should do when it is asked to execute a certain BIOS call. Here's an example where I use OUT to trigger an emulator to do the BIOS stuff: https://github.com/ivop/atari8080/tree/main/cpm22 It also shows how to assemble working BIOS, BDOS and CCP files. Currently it includes the atarihd (1MB) diskdefs, but that could also be the 90kB SD version. Instead of a single OUT and RET, you would need some way to communicate the proper registers to the Atari and read them back after the Atari is finished. You could use a small fixed block of high memory for that.

 

Edit: diskdefs: https://github.com/ivop/cpm65/blob/master/diskdefs

 

I am still working on figuring out how the Atari worked with the Z80 card.  There are some good clues posted in the files provided by @kheller2 on page 1 of this thread.  I am still sorting through it all.  Some of the text files are stored in a format that requires a lot of manual re-formatting to figure out what it really is as I haven't found any application that can easily view them yet.  I've spent some time, this evening, sorting through the files some more and found some more source code that may answer some questions.

 

I do highly suspect that the CP/M card I re-created isn't the card Atari used and that they used the card in the schematic.  This is due to the single line I found:

 

148+        D1F0                             Z80REG  = 0D1F0   ; STATUS, CONTROL AND HANDSHAKE REGISTER  

 

The card I re-created clearly had multiple addresses but I couldn't figure out exactly what they were as the lines are obscured by the chip.  On the other hand, I have figured out the addressing, of the schematic, and this would match.  However, the schematic strongly implies that the only way to pass data between the Atari and the Z-80 was to suspend the Z-80 so the Atari could examine the Z-80's memory.

 

That being said, with the card I've pieced together, all data would be passed one byte at a time via a couple addresses as follows:

 

$D1F0 (w) sets the Z-80 reset line high and starts the Z-80
$D1F1 (r) reads a byte
$D1F2 (w) writes a byte
$D1F3 (r) reads data bit 7 to see if a byte is waiting

$D1F6 (w) sets the Z-80 reset line low to stop the Z-80 (this will be added on the final card)

 

Note that the card doesn't have the R/W lines connected so I decided to make even addresses write and odd addresses read so that A0 could be used as a R/W line.

 

The Z-80's I/O is as follows:

 

Read byte:  A0=0

Check for byte:  A0=1

Write byte:  A0=0

 

It appears that some sort of hand-shaking protocol needs established that defines the device and data.  The Atari will need some host software that passes the data between the Z080 and the devices.

 

From what I've read so far, I am thinking that the Atari loads some boot loader code into memory and lets the Z-80 take over.  So, the Z-80 would need a boot disk for one of the drives.

 

 

 

 

 

Edit to add:

 

I just found this code.  This makes me believe even more that the other board stopped the Z-80 so the Atari could pass data back and forth in the memory:

 

152+       7BF0                             FRAME   = 07BF0   ; ADDRESS OF COMMAND FRAME - IN MEM BANK 3   
153+     7BF1                                     FDEV    =  FRAME + 1   
154+        7BF2                                     FCOMD   =  FRAME + 2   
155+     7BF3                                     FBCL    =  FRAME + 3   
156+        7BF4                                     FBCH    =  FRAME + 4   
157+        7BF5                                     FTL     =  FRAME + 5   
158+        7BF6                                     FTH     =  FRAME + 6   
159+        7BF7                                     FFL     =  FRAME + 7   
160+        7BF8                                     FFH     =  FRAME + 8   
161+        7BF9                                     FSTAT   =  FRAME + 9   
162+        7BFA                                     FX      =  FRAME + 0A   
163+        7BFB                                     FA      =  FRAME + 0B   
164+        7BFC                                     FDVS0   =  FRAME + 0C   
165+        7BFD                                     FDVS1   =  FRAME + 0D   
166+        7BFE                                     FDVS2   =  FRAME + 0E   
167+        7BFF                                     FDVS3   =  FRAME + 0F   
168+   
169+        7C00                             DATAB   = 07C00 ; ADDRESS OF 1ST BYTE IN DATA TRANSFER AREA - BANK 3  

 

 

 

 

 

 

 

Edited March 31 by reifsnyderb

[_The Doctor__]

The Atari pre stuffed the memory card for the Z-80 card, then it loaded it's own bus monitor in it's own base Ram, the Z-80 then took over, the Atari then became the I/O, Video, keyboard et al watching the Registers and Ram. The Z80 was free to communicate with other cards in the 1090. It could suspend the Atari and the Atari could suspend the Z80.

[reifsnyderb]

42 minutes ago, _The Doctor__ said:

The Atari pre stuffed the memory card for the Z-80 card, then it loaded it's own bus monitor in it's own base Ram, the Z-80 then took over, the Atari then became the I/O, Video, keyboard et al watching the Registers and Ram. The Z80 was free to communicate with other cards in the 1090. It could suspend the Atari and the Atari could suspend the Z80.

Close.  The Z-80 could only communicate with other cards through the Atari as the Atari handled the I/O.

[_The Doctor__]

what are all the signals on the ram ribbon?

what signals are on the z80 cards 1090 slot?

 

Edited March 31 by _The Doctor__

[sup8pdct]

I think you would be better off using the Z80 BusRG and wait for BusAK back to halt the z80 so the 6502 could read the ram instead of holding reset. Of course the modesel line will need to be toggled as well.

[reifsnyderb]

5 hours ago, _The Doctor__ said:

what are all the signals on the ram ribbon?

what signals are on the z80 cards 1090 slot?

 

The signals on the RAM ribbon cable:

 

 

The signals on the 1090 slot:

 

 

 

[+kheller2]

12 hours ago, reifsnyderb said:

I am still working on figuring out how the Atari worked with the Z80 card.  There are some good clues posted in the files provided by @kheller2 on page 1 of this thread.  I am still sorting through it all.  Some of the text files are stored in a format that requires a lot of manual re-formatting to figure out what it really is as I haven't found any application that can easily view them yet.  I've spent some time, this evening, sorting through the files some more and found some more source code that may answer some questions.

 

I didn't realize they were that unclean.   I see the page header command in there but it looks like all the returns and line feeds have been removed.  I few quick Unix scripts could clean them up.  Is there something you want me to look at first?

[reifsnyderb]

3 hours ago, sup8pdct said:

I think you would be better off using the Z80 BusRG and wait for BusAK back to halt the z80 so the 6502 could read the ram instead of holding reset. Of course the modesel line will need to be toggled as well.

 

This is how the CPM card in the Atari schematic functioned.  Unfortunately, there isn't a picture of the card.  Also, I was heavily reviewing the files posted by @kheller2 last evening and found that Atari apparently wrote the CPM BIOS to work by halting the Z80 so the 6502 could access the memory.  I confirmed this because I discovered the following structure in memory:

 

142+                                 ;    HARDWARE & Z80 BOARD HARDWARE ADDRESSES FROM 6502 VIEWPOINT   
143+   
144+        0200                             CPM     = 00200 ; OFFSET OF CPM CODE FROM SECTOR 1 TRACK 0   
145+   
146+        BC00                             DDTVEC  = 0BC00 ; TRANSFER ADDRESS FOR DDT  
147+   
148+        D1F0                             Z80REG  = 0D1F0   ; STATUS, CONTROL AND HANDSHAKE REGISTER   
149+         D1FE                             BANKSW  = 0D1FE   ; 64KMR CONTROL REGISTER   
150+   
151+        4000                             Z80Z0   = 04000    ; Z80 ZERO PAGE - IN MEM BANK 0   
152+       7BF0                             FRAME   = 07BF0   ; ADDRESS OF COMMAND FRAME - IN MEM BANK 3   
153+     7BF1                                     FDEV    =  FRAME + 1   
154+        7BF2                                     FCOMD   =  FRAME + 2   
155+     7BF3                                     FBCL    =  FRAME + 3   
156+        7BF4                                     FBCH    =  FRAME + 4   
157+        7BF5                                     FTL     =  FRAME + 5   
158+        7BF6                                     FTH     =  FRAME + 6   
159+        7BF7                                     FFL     =  FRAME + 7   
160+        7BF8                                     FFH     =  FRAME + 8   
161+        7BF9                                     FSTAT   =  FRAME + 9   
162+        7BFA                                     FX      =  FRAME + 0A   
163+        7BFB                                     FA      =  FRAME + 0B   
164+        7BFC                                     FDVS0   =  FRAME + 0C   
165+        7BFD                                     FDVS1   =  FRAME + 0D   
166+        7BFE                                     FDVS2   =  FRAME + 0E   
167+        7BFF                                     FDVS3   =  FRAME + 0F   
168+   
169+        7C00                             DATAB   = 07C00 ; ADDRESS OF 1ST BYTE IN DATA TRANSFER AREA - BANK 3  

 

 

 

 

It took my a while to find this because the files were apparently created with an application that is incompatible with the text editors I am using.  So, everything is a wall of text.  In retrospect, I should have spent a lot of time reviewing these files as soon as they were posted.

 

That all being said, it's clear a new card would have to be made.  So, instead of refining the current card, I am studying how both card schematics could be "combined" so as to use the 6502 DMA strategy.  While I am at it, I may as well see about how I can reduce the chip count on the card.  (Besides, some of the chips aren't made anymore.)  I am also thinking about putting the SRAM right on the card as well.