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

[reifsnyderb]

7 minutes ago, _The Doctor__ said:

For your sector copy use mydos, it should work fine.

As to RespeQT, you may have to pick a different edge timing in it's config depending on your port. (while this matters on a real RS232 port, it seems to affect USB timing ever so slightly as well.)

The sector copier is MTL at fault. What are you using?

 

Where do I set this timing at?

[_The Doctor__]

Tools

Options

Serial port backend

make sure the correct flow control handshake is selected for your specific cable

a check box exists for edge timing (normal or falling edge) slight

at the bottom is further timing in uS for timeouts etc.

 

there are further adjustments for SIO divisor rates as well, greyed out until boxes are ticked.

these appear and disappear based on selections already made that pertain to the functions.

Edited April 22 by _The Doctor__

[reifsnyderb]

11 minutes ago, _The Doctor__ said:

Tools

Options

Serial port backend

make sure the correct flow control handshake is selected for your specific cable

a check box exists for edge timing (normal or falling edge) slight

at the bottom is further timing in uS for timeouts etc.

 

there are further adjustments for SIO divisor rates as well, greyed out until boxes are ticked.

these appear and disappear based on selections already made that pertain to the functions.

These are the options I have....

 

Experimentation shows...

1.  DSR is the handshake method that is used.

2.  I haven't noticed a different with the DTR Control Enable

3.  The High speed mode baud rate seems to work fine.

4.  A non-standard speed, with a low POKEY divisor, results in the program crashing

5.  Keeping the delay at 250us seems to be the trick.

 

There's no check box for the edge timing.

 

I just discovered that if the system pauses, and I wait for 10 or more seconds, it may eventually continue.  I never tried waiting so long when it quit working.

 

Even so, when testing for writes, it clearly completely failed.

 

 

 

 

 

 

 

 

 

 

 

 

Edited April 22 by reifsnyderb

[_The Doctor__]

what version is that?

crashing should never occur.

try RI see if the box appears then DTR and see if the check box appears... (just to see if it's in there somewhere)

I had mine set at 300 so 250 sounds about right.

DTR control is normally used to switch devices between SIO 2 PC computer vs SIO 2 PC drive modes

If this is the latest version with the build crashing, you will need to contact JoSch on discord because that's bad and I haven't seen that since AspeQT days.

I am using Windows as of late so indicate to the team on discord all the normal information/ Linux build ver etc.

Edited April 22 by _The Doctor__

[reifsnyderb]

28 minutes ago, _The Doctor__ said:

what version is that?

crashing should never occur.

try RI see if the box appears then DTR and see if the check box appears... (just to see if it's in there somewhere)

I had mine set at 300 so 250 sounds about right.

DTR control is normally used to switch devices between SIO 2 PC computer vs SIO 2 PC drive modes

If this is the latest version with the build crashing, you will need to contact JoSch on discord because that's bad and I haven't seen that since AspeQT days.

I am using Windows as of late so indicate to the team on discord all the normal information/ Linux build ver etc.

I believe it's supposed to be the newest version.  It also crashes if the log gets too full.  (I have to delete the log file.)

 

I just tried RI and DTR.  There's no extra check box.

 

I guess I'll have to contact JoSch.

 

I guess the most frustrating part is that I've wasted a lot of time trying to troubleshoot this with the assumption respeqt was a known good.

 

 

 

[reifsnyderb]

More troubleshooting.  It could be a bad cable.  I pulled off the shrink tubing and found a resistor wasn't connected.  Re-flowing the solder connections isn't helping yet, either.  <sigh>

[reifsnyderb]

Ok.  I've got one of these coming:  https://www.ebay.com/itm/175793498479

 

It may be here by April 30th.  Another week long delay to see if I really got this thing working.   <sigh>

 

 

[ivop]

On 4/21/2024 at 6:17 AM, ivop said:

It's indeed used to find the BDOS entry for applications to call, but it's also used to determine MEMTOP (MSB used only), and sometimes to calculate the beginning of CCP. I have seen code doing a hardcoded BDOS vector - 00806H = start of CCP. For example The Amsterdam Compiler Kit (ACK) does that.

[snip]

Also found the code in boot.s in ACK:

  Reveal hidden contents

    ! Now the 'heap'.

    lhld 0x0006              ! BDOS entry point
    lxi d, -0x806            ! offset to start of CCP
    dad d
    shld _cpm_ramtop
 

 

Found another one. This time in the official DRI's XSUB (eXtended SUBmit):

    lda bdos+1
    cpi 06h
    jnz loaderr

 

Quote

Ok.  I've got one of these coming:  https://www.ebay.com/itm/175793498479

 

It may be here by April 30th.  Another week long delay to see if I really got this thing working.   <sigh>

Hopefully that one works okay!

 

Edited April 23 by ivop

[reifsnyderb]

19 minutes ago, ivop said:

 

Hopefully that one works okay!

 

Given what I've seen, when things do intermittently work, I think I've got the main parts working.  Sometimes the write test almost completely works.  Sometimes.

 

I also started adding a system so you can interrupt the Z-80.  The idea is that if you are working on a Z-80 program that hangs, that you could trigger an interrupt for debugging.  I figure that control/shift/i would work.  I set the CP/M BIOS to put the Z-80 in interrupt mode 2 so it will run the code at $0030.  For now, $0030 would do nothing but do a warm start.  However, it would be easy enough to jump to a monitor program, for example.  That way somebody could check the memory to try to determine what happened.

 

This came about because the Atari schematic showed that the Atari could lower the Z-80 interrupt line.  So, I kept that functionality but didn't know what I'd do with it when I designed the card.  But it would be useful for debugging purposes.

 

 

 

[reifsnyderb]

Atari's Z-8 0 schematic showed that it should be possible for the Atari to send an interrupt to the Z-80.  So, I kept that capability but forgot to take the Z-80 /M1 signal into account.  If the Atari can send the Z-80 an interrupt, it would help with debugging Z-80 software as it would be possible for the interrupt to exit the Z-80 out of an endless loop or run a machine code monitor.  I decided to run the /M1 signal to the output PLD.

 

Picture of the back side of the Z-80 CP/M card.  The short blue wire is added to support the Atari sending an interrupt to the Z-80.  This line is the M1 line and should be high during normal I/O.  M1 will be low when an interrupt is called.  U22 is now programmed to take M1 into account when handling output from the Z-80 to the Atari.

 

This connection has been added for the next version of the card.

 

 

 

 

 

 

Edited April 25 by reifsnyderb

[Geister]

I spotted this on E-Bay following your link above.  Looks familiar doesn't it?  https://www.ebay.com/itm/296108803958?itmprp=cksum%3A296108803958cd3a959f7bcc457090d07e2e5a2d1b92|enc%3AAQAJAAABcLSVkHmTL63bebovD9RfpraPWbY9f4anjbziTIaEIOVXg2DWhVLks3Lfqff9vxxfjIh4XEXusIehlT2iEH8%2BCxXNySMxlDIQJ3g86%2Bx3AAIAq9gznqdGSR72ksP41kjzPN1reUbVsJuld0S4i4qXlQfTmkMeIJTCXTM8mLpr7ju2fMvruDu87ZX%2B4bShOvD%2B4lfEu09l%2BFuJ2%2FjqrhG1PkWV3RLeRzMpZva5RgvC9Z9GR3FRqqHBTYW3QtOVYXAZs2xsOeXYabwhxWOhVDAuexLseSyJanK0GQHvzFwx5CmKoyFvYi4Cuw3PNrRsIMvrSQdFUzvIubUpPlA2INzGZAKq0JHs1K6BoJgTAZBwtZrqDxAyU0xD6%2FdH1dv6VHCRCFk5zgC6z8KzR1b8ZuJF0ks6UnDjCXr3DqukmEh5bpnqTDfCYJJb9Cu2W331r%2BbwRTai4Zhi%2B6Sjfy9QvT6kXmlZMPW0Dl6qBIxgAeI5G86d|ampid%3APL_CLK|clp%3A2332490&itmmeta=01HWG232FGVNVH46Q6WF5A5ZKP

Edited April 27 by Geister
edited to add link

[Geister]

Just posting the above because VGA on the ATARI 8-bit is within our grasp already.  We just need to complete the work.

[reifsnyderb]

1 hour ago, Geister said:

Just posting the above because VGA on the ATARI 8-bit is within our grasp already.  We just need to complete the work.

Yes, it certainly would be possible.  It would probably have to be done by shadowing the RAM and changes to certain hardware addresses.  Then, the Atari graphics system would be to be re-implemented and output via VGA.  It would be quite a project. 

[Geister]

Considering the progress you've made on the CPM in the short while I've been preoccupied with other things, I'd guess we'll have the path cleared pretty well by the time I get back from the West Coast.

 

It's horrible timing that we are looking at ramping up CP/M just as the Z80 is going EOL but maybe there will be enough units available to proceed for the people still interested.  I'm still hoping to snag a unit off you when I'm home again.

[reifsnyderb]

1 hour ago, Geister said:

It's horrible timing that we are looking at ramping up CP/M just as the Z80 is going EOL but maybe there will be enough units available to proceed for the people still interested.  I'm still hoping to snag a unit off you when I'm home again.

I am waiting on a new USB adapter to use with RespeQt.  Hopefully, this will fix the problem and I can confirm that everything is working.  There are hints that CP/M is working fine.  However, due to the intermittent nature of the disk I/O failures, I can't prove it yet.

 

I still need to add/do:

 

1.  Printer output.  (Should be pretty easy.)

2.  Interrupt handling.  (Partially implemented in software.)

3.  Transferring CP/M utilities into the Atari CP/M disk format.

4.  Creating some method of copying CP/M programs into the Atari CP/M disk format.

[+mytek]

6 hours ago, Geister said:

It's horrible timing that we are looking at ramping up CP/M just as the Z80 is going EOL but maybe there will be enough units available to proceed for the people still interested.

I spec'ed a CMOS version Z80 for my CV-NUC+ design. No reason I see that this CMOS version won't work for the the CPM board as well, since I'm using it to substitute for the original lower speed NMOS part in the ColecoVision.

 

But you're right, I see a last time buy of 6/14/2024 at Digi-key for that part. However they still have over 1,500 in stock, so I would think they would sell off the stock they have. Mouser also has a bit over 600. Time to stock up

 

Digi-Key P/N: 269-3895-ND

MFR P/N: Z84C0008PEG

CMOS Z80 1 Core, 8-Bit 8MHz 40-PDIP

 

Octopart Search

 

 

[sup8pdct]

8 hours ago, reifsnyderb said:

 

4.  Creating some method of copying CP/M programs into the Atari CP/M disk format.

What about ATCOPY.com? Does it copy cpm > cpm or dos 2 <> cpm?

[reifsnyderb]

6 hours ago, sup8pdct said:

What about ATCOPY.com? Does it copy cpm > cpm or dos 2 <> cpm?

I am not sure.  I am also not sure if it would be compatible with the Atari CP/M format for an ED disk.  Maybe it should be de-compiled?

[+scorpio_ny]

16 hours ago, reifsnyderb said:

I am waiting on a new USB adapter to use with RespeQt.  Hopefully, this will fix the problem and I can confirm that everything is working

Are you doing any testing with any other I/O devices (i.e. real drives, Atari RAM disks, SDrive max)?

[ivop]

52 minutes ago, reifsnyderb said:

I am not sure.  I am also not sure if it would be compatible with the Atari CP/M format for an ED disk.  Maybe it should be de-compiled?

The AT* tools all run on CP/M, so I assume ATCOPY copies files from DOS 2 disks to CP/M disks. Compatibility with ED is handled by BDOS+BIOS. The dumps are not correct though. They include a zeroed page zero. I suppose if you cut of the first 256 bytes, they will work. I can run them through a disassembler if you want to. They are fairly small. The idea is that ATFORMAT formats a disk (that would have to be changed to ED, not sure how it signals the Atari to do the format command instead of R/W) and run ATSYSGEN to copy the bootblock to make a bootable "system" disk.

 

BTW if you are running short on disk space in the bootblock if you add terminal handling and debugging capabilities, you might want to have a look at https://github.com/davidgiven/cpm65/blob/master/src/lib/loader.S .

That's a small loader that knows just enough about the CP/M filesystem to load files (bios.sys, bdos.sys, ccp.sys) instead of including them in the bootblock, provided that 1) the file occupies exactly one extent, 2) it contains no empty blocks, 3) it's on drive 0, and 4) the file exists. If you decide to use that, you might even cut back on the number of reserved tracks to 2 or even 1.

 

Re debugging via a Z80 interrupt. There's DDT.COM which you might want to overlay. It's a weird beast though, as it consists of multiple parts of which the first one is a relocator to upper memory, the second and third part are the actual program that gets relocated, and the fourth part is the relocation table. I recently setup a github repo that builds all of CP/M 2.2 from source with an ISIS-II PL/M-80 cross-compiler, an ISIS-II ASM80 cross-assembler, and a DRI ASM compatible cross-assembler. There was no native tool to generate the PRL (Page ReLocation) table, so I wrote a small utility to do that. The repo is here: https://github.com/ivop/cpm22-from-source

 

Another possibility would be to run the debugger/monitor at the Atari side. You are basically a "Freezer" for the Z80. The only thing the Z80 IRQ handler should do is save its registers somewhere the Atari can read them. You could hide that small routine in the BIOS. That way you do not have to overwrite any (upper) memory with DDT or another monitor/debugger, which might conflict with the running application you are trying to debug.

 

Edited April 28 by ivop

[reifsnyderb]

4 minutes ago, scorpio_ny said:

Are you doing any testing with any other I/O devices (i.e. real drives, Atari RAM disks, SDrive max)?

CP/M has the drive format set in the BIOS.  That being said, I have two nice 1050's that are patiently waiting to participate in the testing.   🙂

 

[+scorpio_ny]

55 minutes ago, reifsnyderb said:

CP/M has the drive format set in the BIOS.  That being said, I have two nice 1050's that are patiently waiting to participate in the testing.   🙂

 

Can you explain in more detail what that means? Does this mean that the storage is limited to certain devices?

[reifsnyderb]

56 minutes ago, ivop said:

The AT* tools all run on CP/M, so I assume ATCOPY copies files from DOS 2 disks to CP/M disks. Compatibility with ED is handled by BDOS+BIOS. The dumps are not correct though. They include a zeroed page zero. I suppose if you cut of the first 256 bytes, they will work. I can run them through a disassembler if you want to. They are fairly small. The idea is that ATFORMAT formats a disk (that would have to be changed to ED, not sure how it signals the Atari to do the format command instead of R/W) and run ATSYSGEN to copy the bootblock to make a bootable "system" disk.

 

BTW if you are running short on disk space in the bootblock if you add terminal handling and debugging capabilities, you might want to have a look at https://github.com/davidgiven/cpm65/blob/master/src/lib/loader.S .

That's a small loader that knows just enough about the CP/M filesystem to load files (bios.sys, bdos.sys, ccp.sys) instead of including them in the bootblock, provided that 1) the file occupies exactly one extent, 2) it contains no empty blocks, 3) it's on drive 0, and 4) the file exists. If you decide to use that, you might even cut back on the number of reserved tracks to 2 or even 1.

 

Re debugging via a Z80 interrupt. There's DDT.COM which you might want to overlay. It's a weird beast though, as it consists of multiple parts of which the first one is a relocator to upper memory, the second and third part are the actual program that gets relocated, and the fourth part is the relocation table. I recently setup a github repo that builds all of CP/M 2.2 from source with an ISIS-II PL/M-80 cross-compiler, an ISIS-II ASM80 cross-assembler, and a DRI ASM compatible cross-assembler. There was no native tool to generate the PRL (Page ReLocation) table, so I wrote a small utility to do that. The repo is here: https://github.com/ivop/cpm22-from-source

 

Another possibility would be to run the debugger/monitor at the Atari side. You are basically a "Freezer" for the Z80. The only thing the Z80 IRQ handler should do is save its registers somewhere the Atari can read them. You could hide that small routine in the BIOS. That way you do not have to overwrite any (upper) memory with DDT or another monitor/debugger, which might conflict with the running application you are trying to debug.

 

It sounds like the program dumps need disassembled and fixed either way.  If you could disassemble the atcopy and/or atformat commands that would be great!  I was thinking about doing the same, but was unsure as to whether it is Z-80 code or not.

 

The bootblock is getting tight.  But there is still some extra space for the BIOS.  I think it's enough.  If not, I like the boot loader idea.

 

There could be a "special" BIOS command for special Atari functions, such as format.  I saw an extra BIOS command, in the Atari CP/M BIOS dump, that may be involved.

 

Is an "extent" a block?  i.e.  1024 bytes?  I am unsure of that term.

 

I've been using the Atari wozmon as a debugger/monitor for now.  I do have to send the Z-80 a bus request command first.

 

Thanks!

 

 

 

[reifsnyderb]

1 minute ago, scorpio_ny said:

Can you explain in more detail what that means? Does this mean that the storage is limited to certain devices?

Yes, CP/M will limit the device format, specifically.  When CP/M was first created, all the disk interfacing software was part of the BIOS.  Even the interleave factor was set in the BIOS.  With the Atari, however, there is some abstraction as CP/M sends the track/sector information to the Atari I/O software.  The Atari I/O software converts it into a sector.  The sector is sent to the disk drive.  The disk drive then converts the sector back into a track/sector.   lol

 

I did see a note, somewhere, about the possibility of some sort of CP/M BIOS (or modification) that would permit multiple disk drive types and/or formats.

 

Any RAM Disk system could easily be set to provide a RAM disk only if the memory is found.  It wouldn't be too hard to program the system to automatically set the RAM Disk based upon how much extended memory is found, either.

[ivop]

2 hours ago, reifsnyderb said:

It sounds like the program dumps need disassembled and fixed either way.  If you could disassemble the atcopy and/or atformat commands that would be great!  I was thinking about doing the same, but was unsure as to whether it is Z-80 code or not.

It doesn't really matter if it's 8080 or Z80 code as long as your disassembler is Z80. As a bonus, you get Z80 mnemonics instead of the horrific Intel 8080 mnemonics.

 

2 hours ago, reifsnyderb said:

The bootblock is getting tight.  But there is still some extra space for the BIOS.  I think it's enough.  If not, I like the boot loader idea.

 

There could be a "special" BIOS command for special Atari functions, such as format.  I saw an extra BIOS command, in the Atari CP/M BIOS dump, that may be involved.

I started disassembling atformat, and it does indeed send a special BIOS command to the Atari. For fun, I tried Ghidra in Z80 mode, but it does not have a proper export to assembly. I am expected to write code for that, which I'm not going to do. Reko constantly crashes, so I guess it's back to the z80dasm command line utility Perhaps it's easier to write format and sysgen from scratch. We can even do that in C and compile with the Amsterdam Compiler Kit. Format just needs to read the drive name from the command line (from cpm_fcb), ask for Y/N, and send the format command to the Atari. Sysgen is basically a sector copier that copies the bootblock from drive x to drive y, which is also trivial in C.

 

2 hours ago, reifsnyderb said:

Is an "extent" a block?  i.e.  1024 bytes?  I am unsure of that term.

An extent is the portion of a file controlled by one directory entry. There can be up to 32 extents to make up one file. If the disk size is <256 blocks, the allocation vector contains a maximum of sixteen bytes (block references) per extent. Otherwise it contains eight lsb/msb words (block references) per extent.

 

2 hours ago, reifsnyderb said:

I've been using the Atari wozmon as a debugger/monitor for now.  I do have to send the Z-80 a bus request command first.

Ah, IIRC that's a Z80 port of wozmon, isn't it? Is it small enough to fit in the BIOS?

 

Edit: BTW the original 8080 SYSGEN.ASM is available. I'll look into what it exactly does and if it's enough to just copy the bootblock from one drive to another.

 

Edit2: I think we can just use the standard SYSGEN.ASM. It has hardcoded sector skew translation, but that can be turned into a no-op with the right table. I think the 1,2,3...,26 table we use (I used the same in my 8080 emulator) is wrong though. It should be 0,1,2...,25 as the Atari counts from zero, like BDOS, and not from 1, like the MDS-800 floppy controller which most of DRI's default code is written for.

 

Edit3: attached atsysgen.zip. Contains official DRI source, modified for 3 boot tracks and sectran to a no-op, and the resulting binary.

atsysgen.zip

Edited April 28 by ivop