ATR-8000 (and other) CP/M System disks here

[sup8pdct]

 

Still struggling with z80 assembly. This code appears in ATARI.MAC file.

**************************************

;

;

; ... PRINTER STATUS COMMAND PROCESSOR ...

;

PTRSTAT:

CALL SENDACK

LD HL,PSMSG

LD DE,IOBUFF+LEN-4

PUSH DE

LD BC,4

LDIR ;COPY PRINTER STATUS FRAME FROM RAM

POP HL

LD DE,'C' ;SEND PRINTER STATUS UN-INVERTED

JP SENDBUFF

; ret

;

;

; ... PRINTER WRITE COMMAND PROCESSOR ...

;

PTRWRITE:

CALL SENDACK ;SEND 'ACK' FOR COMMAND FRAME

CALL RECVBUFF ;GET PRINT DATA FROM SERIAL BUS

RET NZ ;EXIT IF ERROR OR TIMEOUT

*******************************

Not sure if commenting out the

; ret

is a mistake or the coder trying to save a couple of bytes by having the routine run through to PTRWRITE and hit the RET there.

 

This code is only reached if you have a serial printer hooked up to the ATR8k and the system configured as such. Considering the comments on the rest of the code, a little odd that it would be done and not explained.

 

It will never get to the commented out RET. the JP sendbuff means the program JumPs to sendbuff. same as JMP in 6502. CALL in z80 is same as JSR in 6502.

 

James

[a8isa1]

The online sources say there was a ROM update. You should be able to lift the hood and the EPROM will have a label on it that shows version 3.02 which is the latest. They handed out ROMs to anyone who had an early

http://www.atarimagazines.com/v2n4/productreviews.html

 

Assuming the files in the early production ROMs are labeled i.e. minimon.mac.orig in the source distribution, you would still have the D[ump] command. Just boot to the ATRMON prompt and type DF000<return>, if you get 128 bytes of data dumped to the screen, you have the original ROM. If it just ignores you, you have the latest.

 

My serial number, on the back by the 34 contact edge connector, is 001464 which makes me wonder if they started counting from zero. That would mean a lot more ATR8k out in the wild then I would have thought. Mine also has a little green circle sticker on it with '16' on it => inspector 16? Trivial fix if anyone needs an update ROM since I can burn them a new one.

Thanks Rick!

 

I'll try the monitor shortly but "3.02" sounds very familiar so I probably won't be opening the ATR8000 just yet. Will have to soon. The lamp in the power switch has been flickering for some time now.

 

My serial number appears to be simply 2232 with no leading zeroes. Inspected by 64.

 

BTW Rick, there's an autoterm-80 in the wild and a while back Claus Bucholz released an image of DT-80 cartridge, terminal software for ATR8000.

 

Sorry I can't find the autoterm-80. Pretty sure it's somewhere here in Atariage forums as is DT-80.

 

-SteveS

Edited May 20, 2014 by a8isa1

[AtariGeezer]

My serial number is 000130, I'll pull the rom in a few hours and see if I have the older version...

Hope to have mine back up and going tonight

My ROM is also a "3.02"...

[+warerat]

Couple of comments. When I reworked the source, I first assembled what was originally provided (with some syntax changes) and then did a byte compare with my ROM (mine has a printed label of "3.02+"). I renamed the originals .orig with the exception of rom.mac, but really there are only a handful of differences between the original commented source and what I patched:

 

- rom.mac : There is an additional byte, $95 that was not in the original but is in my ROM. No idea why it is there as it isn't referenced anywhere. I added the macro at the end to align the "ATR8000 ver 3.02" text string to the end of a 4K boundary that was missing from the original, but it doesn't have to be there.

- diskio.mac : Delay appears to have been shortened from original source in subroutine "RESTORE". Original had 30, ROM had 0.

- minimon.mac : The 'D'ump feature was not on the production ROM, so I commented this out

- globals.mac : Another mystery byte here, $73

 

The changes above yielded an exact byte-for-byte match to what I have and also matches what was posted earlier in this thread.

 

The ATR8000 is strapped for an 8K ROM, so you could conceivably add the dump code back and fit it on a 2764, assuming the ram-resident BDOS doesn't bump up against $F000 in the memory map and the CP/M jump vectors are left undisturbed. I'll probably end up doing that later this week just for fun.

 

My ATR8000 is serial # 2675 with a fully populated Co-Power88 daughter board underneath with 1MB of memory. I have made dumps of the PAL on the Z80 daughter card, the PROM on the mainboard, and the EPROM for the Co-Power88 if anyone needs them.

 

Thanks to you guys for your work and dedication to getting these disk images squared away.

[a8isa1]

I have hand assembled this CPM disk with some files on it. No idea if this will work.

 

Just disk copy the atr to a real floppy on a DD drive and make sure it is single sided . Wipe the disk before you format and write this out.

 

Am hoping the CPM files will load and work ok.

They are DDSYSGEN for the latest version only (27-april-1984).

DDINIT to format disks

SYSTEM.SWP that DDSYSGEN can use if asked to.

 

Feedback please.

 

James

James,

 

I blanked the disk, formatted it single sided, and sector copied cpmtest1.atr to it. then I tried

 

- to boot it as a system disk. I didn't expect it to work and it didn't

 

- I used ATR.XEX and wrote the system tracks to the disk. I tried to boot this disk and it did work. DIR revealed your 3 files but also 14 lines of this

 

A:>: :

 

When I try to run DDSYSGEN the system hangs immediately.

 

When I try to run DDINI I get 'ERR 04' and the ATRMON prompt, '#'

 

- I repeated building the disk. this time I used a different disk to boot from. I saw pretty much the same as the previous example.

[sup8pdct]

James,

 

I blanked the disk, formatted it single sided, and sector copied cpmtest1.atr to it. then I tried

 

- to boot it as a system disk. I didn't expect it to work and it didn't

 

- I used ATR.XEX and wrote the system tracks to the disk. I tried to boot this disk and it did work. DIR revealed your 3 files but also 14 lines of this

 

A:>: :

 

When I try to run DDSYSGEN the system hangs immediately.

 

When I try to run DDINI I get 'ERR 04' and the ATRMON prompt, '#'

 

- I repeated building the disk. this time I used a different disk to boot from. I saw pretty much the same as the previous example.

Ok. thanks.

Something is WAYYYYYY!!!! out of wack.

I figured that maybe the block size is 2048 just like on the ATR8000 disk image, but it has 1024 byte sectors as well.

Maybe the 256 byte sector disks have 1024 byte blocks. Will need to re work it heaps. And try it again.

At least i got the directory in the right place.........

 

James

[Caterpiggle]

Yes, you are right , I suspect that I might have CO-Power 88 because I has the manual book of Co-Power first place.

[sup8pdct]

Here is version 2.

Use utility to write system tracks and please tell me what happens.

 

James

cpmtest1.atr

[AtariGeezer]

Hmmm, I tried my ATR8000 tonight using an old standard 360k drive, a drive mech out of a XF551 and a Tandon TM-100 SSDD drive and all had the same results. After booting AtrMon from a 1050 as D1:, I turned off the 1050 and tried to boot a CP/M disk, but all 3 standard drives returned Error #10...

They would all rattle like they were trying to step to track #0. I turned the floppy over and would return Error #80.

 

The ATR8000 won't even boot a SSDD mydos 3.18 floppy that was written years ago, asks like the ATR8000 doesn't even see the drives...

 

Anyone know the definition to the error codes or why it would act that way?

[Caterpiggle]

So your ATR8000 still refusing to using your internal XF551 Drive ? Stubborn in error number ??

[ricortes]

 

- diskio.mac : Delay appears to have been shortened from original source in subroutine "RESTORE". Original had 30, ROM had 0.

- minimon.mac : The 'D'ump feature was not on the production ROM, so I commented this out

- globals.mac : Another mystery byte here, $73

 

<many snips>

 

The ATR8000 is strapped for an 8K ROM, so you could conceivably add the dump code back and fit it on a 2764, assuming the ram-resident BDOS doesn't bump up against $F000 in the memory map and the CP/M jump vectors are left undisturbed. I'll probably end up doing that later this week just for fun.

 

 

Last time I will remind everyone; My z80 skills are weak.

 

That being said, the end of the ROM has the name and version stored right at the top i.e. ~$ff0. When looking for a quick and dirty way to find the version number in system I did a memory dump of the CMP area on a running system with DDT, ATARIMON and ATRMON, couldn't find it. Waded through some more ROM source code and it looked like the entire ROM *IS* copied to high RAM before being disabled. The system programmer<s> didn't bother clearing RAM after the boot RAM test, I find alternating bytes of $00 $FF in low RAM. I think the only thing they did ZERO was the piece of high RAM where the name/version would have been!

 

I think it should be possible to switch out RAM for ROM briefly to read the i.d. Probably just involves disabling interrupts and moving the last page of ROM to a safe memory area. Not really important since the proof is in the pudding. If it works, it works, no matter what version of ROM, just a little more limited.

 

I've been getting a lot of problems with my setup. The problems atari8maestro/Other Rick found with SIO2PC not playing nice with the ATR8000 are accurate. I would have said the MAX232/1489 loading the bus problem, then I realized I don't have either in mine! I'm using a 74LS00 hack I put together years ago. IOW: A single ttl load on the SIO bus is enough to glitch the ATR8000. I am working around it by just unplugging the SIO2PC cable after booting for now. I'll look into it. I could just add a pull up like OR did but for some reason => since SIO2PC plays nice with everything else in the world, the ATR8000 may need some work or a hack to get it to play nice. Something like a non inverting buffer between the ATR8000 and the outside world mounted in SIO2PC fashion. Too much of a drag unplugging stuff. Then again, maybe a non inverting buffer on the SIO bus like a 4050 would be a good idea in general. Never can tell when someone will hang 4 drives, an ATR8000, printer, 850, on the SIO bus. It would give some level of protection for our $10 POKEY chips with a $.50 IC.

 

I did the 'drive 50 miles' to find parts for redoing my floppy cables. I can't be sure until after I replace them, my 30 year old cables seem to be producing more errors so I'd rather be safe. I would get mundane problems like formatting my disks under Atari DOS, SD, or CP/M. Picked up a bunch of EPROMs while I was at it. Everything from 2732 to 27010. Didn't need the 27010 but they were selling 10 for $4.95 so I couldn't resist.

Edited May 21, 2014 by ricortes

[ricortes]

Mine stated "64" yellow sticker. So it is 64 K. So must I uncover my 360K XF551 disk drive and plug the ribbon cable and hook up to the back of my ATR8000 and will it works ? Of course, I will leave the power source inside XF551 that still hook-up to internal drive itself. The serial number 000297.

If you have a working XF551, that would be too risky. The PC boards are just too fragile.

 

Two questions, 1) Are you in the USA 2) Do you remember those old dual floppies in a single enclosure? The ones that had a 5.25" and 3.5" built into a single 5.25" drive? One of the old computers I bought had one of the dual drives in it with the 3.5" mechanism busted. The whole computer only cost me $10 and it is my work computer for the ATR800 stuff. I will give you the 1.2 meg drive for the cost of shipping if you promise not to take apart your XF551! They are that precious and rare.

[a8isa1]

Hmmm, I tried my ATR8000 tonight using an old standard 360k drive, a drive mech out of a XF551 and a Tandon TM-100 SSDD drive and all had the same results. After booting AtrMon from a 1050 as D1:, I turned off the 1050 and tried to boot a CP/M disk, but all 3 standard drives returned Error #10...

They would all rattle like they were trying to step to track #0. I turned the floppy over and would return Error #80.

 

The ATR8000 won't even boot a SSDD mydos 3.18 floppy that was written years ago, asks like the ATR8000 doesn't even see the drives...

 

Anyone know the definition to the error codes or why it would act that way?

No clue on the error codes. ATR8000 is very sensitive to drive termination. The last drive on the chain needs to have the resistor network and the others can't have one.

 

I've never had any drives other than those connected to ATR8000 itself. However, the ATR8000 has always performed poorly with anything else on the SIO chain. with 2 or 3 SIO2PCs the ATR8000 became invisible, even if the SIO2PC was connected at the other end. with a couple SIO2PC I could eek out 1X SIO (to the SIO2PC) and the ATR8000 but there would be intermittent sector retries.

 

for a classic RS232 connected SIO2PC some years ago I read about a solution and it worked for me. That solution was inline resistors on the SIO2PC for COMMAND and DATA SEND. Values recommended were 1500 to 2000 ohms. I think 2K2 worked for me.

 

I/O worked 1X through 3X (to the SIO2PC) and ATR8000 worked but still with the occasional retry here and there.

 

I think I read about that solution on comp.sys.atari.8bit.

 

I can't figure out why my old SSDD drives aren't working. I dug them out to see if they made any difference with

 

sup8pdcts' tests. I don't understand why I'm having troubles. These are the drives I used from 1984 until about 4 years ago when I was given a PC with a pair of 360K drives.

 

Anyway, looking forward to trying the new disk image.

 

-SteveS

[ricortes]

Not to bash someone who for years supported Atari with web pages full of schematics.

 

The pull up resistor he added to my design running to the diode is tits on a bull. I'm 99% sure the Atari 8 bit already has the line pulled up so this was superfluous. Probably done on the POKEY silicon, I should look at schematics. That would be why when you boot your Atari with nothing attached, you don't get anything other then the standard not there squawks rather then have it boot from the rooms florescent lights. The one OR added, I can't tell where because that particular piece of his web site is not there or in archive. And once again, I have a 74LS00 for my interface so all the 1489 vs MAX232 is academic. For the record, the MAX232 has the same exact specs as the 1489 for bus loading, so that isn't it. Likewise I don't want to bust OR chops as he has a better history and reputation then myself, but guessing he just changed from a 4.7k resistor to a 680 Ohm is suspect. I mean it may work but it probably doesn't work for the reasons given.

 

The inline resistors you cite do make sense and would probably work as they should. I be thinking isolation via diodes like existing one would be as simple/best. Reverse resistance on a diode is >200k Ohm so they would provide the best isolation 10x better then they working resistor design!

 

I've been looking at the ATR8k schematics and they appear to use a 4069 as an input buffer. The 4069 is a CMOS part. It would not have been my choice, they tie them end to end to get a non inverting function. Better would have been a 4050. It should work, that it doesn't has me puzzled. I may truck around with a 74HC4069 or 74HTC4069 to see if that helps w/o being too strenuous. I think this is liable to only be solved with a DVM and oscilloscope.

[fibrewire]

The inline resistors you cite do make sense and would probably work as they should. I be thinking isolation via diodes like existing one would be as simple/best. Reverse resistance on a diode is >200k Ohm so they would provide the best isolation 10x better then they working resistor design!

 

+1 for using diodes for isolation. Less delay and higher speeds.

[ricortes]

I may diverge for a bit.

 

Taking in all that has been said: I looked at the ATR8k schematic, shows A12 floating<probably over site in drawing and not the MB> but yes, looks like a 8k EPROM could go in there.

 

Six of one, half dozen of another. You could lower the CPM head by 4k, use a 2764, and end up with a still nice CPM system. I'm thinking that isn't the way to go though. What makes more sense is doing a switchable OS similar to what we do with our Atari. That way you would have access to the original 3.02 ROM for backwards compatibility and a fixed one.

 

Reason for this is the odd sector layout of the system tracks, I hate it, I hate it, I hate it! In order to get this to work, they use a subroutine that builds up the track data in RAM and puts the FDC under processor control. Most importantly, they don't do it right. By that I mean programs like Teledisk have no problems doing an Atari disk with different sector sizes, but chokes on anything ATR8k. i.e. report 110 sectors per track with the first 128 byte sector empty.

 

So for the last couple of days I have been sweating the details. For example, if you use IBM 9 sector of 512 bytes/track, all the IBM tools are available to you. The down side is as it is written, you would waste 512-128 bytes for the first sector on both system tracks and 1024 bytes with two less sectors for the those tracks.

 

From ATRMON, B(oot) gladly loads the first sector of an IBM formatted disk. Fooling around with 22DISKS, I found the Cromeco CRO6 10 sectors per track formatted disk loads too. I put the boot code from sector 1 on the first track of a Cromeco formatted disk and sectors 2-9<all I could write with DEBUG since IBM BIOS thinks sector 10 is on track 1>

 

So, I just hit B<RETURN> from the monitor, errored out and back to the monitor. From there I just tagged G80, this goes to the routine that was loaded in step one but not executed because of an error, and the routine loaded CPM from D400-E130. That is just a bit short because I didn't finish the sector editing. Not sure what happens when it hits track 1 either.

 

I also fooled around with the boot code James pointed out. Turns out you can just change the DCB and get it to point anywhere in memory, then jump to it and load data. I *THINK* I was getting that routine to load 512 byte sectors into memory locations ~$1000, lack of familiarity makes me unsure it wasn't left over from another routine. => Simple fix for loading OS would be to have CPM starting from $80 on the first sector and just do the load from $D400-$80. $D380-$D3FF would have the boot code + garbage from the first $80 bytes of the sector, but it wouldn't make a difference. Still sweating 9 vs. 10 sectors!!!

 

None of this makes a difference. Specifically James has everyone booting now so no one needs it. Just a bit obsessive in that I would rather see the system just a little more conventional. It's a perfectly valid and viable solution to someone who found an ATR8k to tell them "1st step to getting it running is to go out and buy an Atari 8 bit to act as a terminal." I would just like to see Teledisk as an option too. So if I get a little unresponsive, just that I am looking at something different.

[a8isa1]

Here is version 2.

Use utility to write system tracks and please tell me what happens.

 

James

After booting I get. "NO FILE".

 

Sorry.

[sup8pdct]

damm IT.

 

James

 

Edit:

DOH!!!!!! I see what i forgot to do....... Didn't invert the data.............

 

Fixed that bit. please try this one.

 

 

 

cpmtest1.atr

Edited May 22, 2014 by sup8pdct

[a8isa1]

damm IT.

 

James

 

Edit:

DOH!!!!!! I see what i forgot to do....... Didn't invert the data.............

 

Fixed that bit. please try this one.

 

 

 

Same result.

 

-SteveS

 

[edit]]

sorry. My mistake this time. I forgot to sector copy the disk image after formatting the disk

Edited May 22, 2014 by a8isa1

[a8isa1]

damm IT.

 

James

 

Edit:

DOH!!!!!! I see what i forgot to do....... Didn't invert the data.............

 

Fixed that bit. please try this one.

 

 

 

It works. I can boot, read the directory, and run every program that is there.

 

I still see several lines of ": : : :' at the end of the directory listing.

 

-SteveS

[ricortes]

It works. I can boot, read the directory, and run every program that is there.

 

I still see several lines of ": : : :' at the end of the directory listing.

 

-SteveS

Just a by the by. That program I posted "CSAV69.ZIP" page 3 of this thread is almost load and go for putting system on a disk. Just unzip it, use 22DISKS to move it to a data disk and it should appear on a booted CP/M system directory. From there, just type CSAV69 at the command prompt and it should go from there.

[a8isa1]

Just a by the by. That program I posted "CSAV69.ZIP" page 3 of this thread is almost load and go for putting system on a disk. Just unzip it, use 22DISKS to move it to a data disk and it should appear on a booted CP/M system directory. From there, just type CSAV69 at the command prompt and it should go from there.

Thanks but I don't have DOS machine or a machine with a 5.25 drive these days. I don't even have a Windows box.

[sup8pdct]

That is good.

There are files on that latest disk to format new data disks, make them bootable and copy files over.

 

Am slowly working at hand assembling the rest of the files on to the ATR image.

Maybe will dump the text files here.

 

James

[sup8pdct]

This should be it. All files that are on the ATR8000.TD0 image should be on this that can be created with any SS DD drive and can read on the ATR8000 floppy mech running CPM.

 

Please test for me and let me know how it goes.

You should be able to read the MAKESYS.doc file and do as it says to make copies.

 

James

CPMFILES.atr

[a8isa1]

This should be it. All files that are on the ATR8000.TD0 image should be on this that can be created with any SS DD drive and can read on the ATR8000 floppy mech running CPM.

 

Please test for me and let me know how it goes.

You should be able to read the MAKESYS.doc file and do as it says to make copies.

 

James

Everything looks great except the program MAKESYS.COM seems to hang. I don't know what it's supposed to do so perhaps I'm not using it correctly.

 

[EDIT]

After reading rcortese's message and rereading your instructions I realised that the MAKESYS.DOC file is mistakenly named MAKESYS.COM.

 

-SteveS

Edited May 23, 2014 by a8isa1