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

[sup8pdct]

Indeed it is, BUT it is the relocatable version that requires another program to set all the jump and code pointers to make it relocatable. This one needs to load at location zero. Considering the boot loader is at $80 and all loaded programs start at $100, a problem develops real quick.

 

James

[ricortes]

I'm got up to four responses lost by hitting the back key!!! Damn you IBM! Anyway, if you are saying the $80 ORG part of that source code you uploaded makes no sense, you are right. Since a Z80 starts execution at PC $00, on boot there has to be ROM there, and 100 other reasons I don't feel like typing in yet again. A better description and source file for CP/M can be found on Grant Searle's site http://searle.hostei.com/grant/cpm/#ROMFiles

 

They match pretty closely except for much better subroutine names, that bit of nonsense code, and the BIOS as Kyle warned against.

[sup8pdct]

The system.swp file is what i was talking about. It cannot be used to make a cpm system boot disk by it self. It has been assembled at location zero. Another program is required to set all jump locations and pointers. At the start of the system.swp files is the boot loader (128 bytes) that the atr monintor program loades to location $80, then hands control over to load the rest of cpm, bios plus overlay. Cpm in the atr starts at $D400, but custom versions can be made to run at different locations which is where system.swp comes into play.

The atr rom starts at $0 but the first thing it does is copy most of itself to $F000 and disable the rom.

I have (i hope) a cpm bootable disk but as my atr isn't working properly, i cannot test it. I am not sure if the first sector being 512 bytes will work. The 3 system td0 images all have 128b first sector sooo......

 

You should try usong a 7" tablet for this. Keys are so small for large fingers thay i keep hittihh thr wronf kets......

 

James

[ricortes]

I think I am going to advise you to give up on me, at least for the near future.

 

I may just be having trouble with the 'why do it that way?' part of that 128 byte loader. More I read, farther away I get from understanding it. There's probably some obvious reason to do things that way, like 16k and 64k ATR8000 but I am still having trouble with it. IIRC the 64k ATR8000 was the only one capable of running CP/M so even that doesn't make sense.

 

I get why the copy what you need from ROM and disable ROM happens, namely because CP/M expects a clean slate from memory location zero where the ROM was for work space and loads itself into high memory. The problem I have among others is the double copy/duplicate function??? See if you follow this or if it even can be followed. ROM was at PC 0. ROM moves itself above where it used to be in RAM somewhere. ROM is now disabled by software so it is a 64k RAM system running from RAM. Now why put a boot loader in that RAM that loads a boot loader into $80 that boots CP/M? There's too many instances of boot loaders. Why not just have your boot loader in RAM and run from there instead of a hotly contested memory area? You know where your system files all go, so just pick a location that is safe from them and boot from there. There is no good reason to have a boot loader loaded from a disk by a boot loader in RAM.

 

No big thing. You scared me a bit with your ATR8000 not running though. I think it has been >10 years since I last ran mine so I should check it. I did get a couple of packs of disks, one set is 5.25" HD which I don't think I have a drive for and a set of 5.25 DD4D which should work fine in a 360k drive. No commitments until Sunday so I will see if I can get my act together before bedtime.

[a8isa1]

I think I am going to advise you to give up on me, at least for the near future.

 

I may just be having trouble with the 'why do it that way?' part of that 128 byte loader. More I read, farther away I get from understanding it. There's probably some obvious reason to do things that way, like 16k and 64k ATR8000 but I am still having trouble with it. IIRC the 64k ATR8000 was the only one capable of running CP/M so even that doesn't make sense.

 

I get why the copy what you need from ROM and disable ROM happens, namely because CP/M expects a clean slate from memory location zero where the ROM was for work space and loads itself into high memory. The problem I have among others is the double copy/duplicate function??? See if you follow this or if it even can be followed. ROM was at PC 0. ROM moves itself above where it used to be in RAM somewhere. ROM is now disabled by software so it is a 64k RAM system running from RAM. Now why put a boot loader in that RAM that loads a boot loader into $80 that boots CP/M? There's too many instances of boot loaders. Why not just have your boot loader in RAM and run from there instead of a hotly contested memory area? You know where your system files all go, so just pick a location that is safe from them and boot from there. There is no good reason to have a boot loader loaded from a disk by a boot loader in RAM.

 

No big thing. You scared me a bit with your ATR8000 not running though. I think it has been >10 years since I last ran mine so I should check it. I did get a couple of packs of disks, one set is 5.25" HD which I don't think I have a drive for and a set of 5.25 DD4D which should work fine in a 360k drive. No commitments until Sunday so I will see if I can get my act together before bedtime.

Out of my league here so just a quick thought and then a real solid lead

 

The ATR8000 ROM is different than from other CP/M machines in that not only does it contain the BIOS but also the emulation code for Atari disk drives, serial and printer ports. I'm not saying that why the multiple loaders and relocations exist. I'm just posing the idea.

 

A while ago I passed source code of the ATR8000's BIOS to someone who might, and certainly did, know what to do with it. That person was warerat. I believe I read (elsewhere in these forums) the he fixed up the code so that it will compile to a binary that matches the ROM in his ATR8000.

 

I don't remember where or when I acquired the source code but I had lost it during a string of PC and disk drive failures. I had forgotten that I shared it with warerat. I'm glad it's not completely lost. You can find his edited version here.

 

Someone mentioned (also elsewhere in these forums) that they would like to upgrade the ATR8000's firmware to support ultraspeed SIO (ALA Indus GT). I don't know if it's possible but I would love to see that too.

 

-SteveS

Edited January 4, 2014 by a8isa1

[ricortes]

Sounds doable. From the file link you just gave

; ... BAUDRATE AND TIMING CONSIDERATIONS ...

;

; THE FOLLOWING TABLE DETAILS THE BIT TIMES FOR THE BAUDRATES

; SUPPORTED BY THE ATR-8000 AND THE CTC PROGRAMMING PARAMETERS

; REQUIRED TO GENERATE THEM USING THE CTC IN THE TIMER MODE.

; (IE. BY DIVIDING DOWN THE 4MHZ CLOCK WITH 16 OR 256 PRESCALE.)

;

; BAUD PERIOD MODULUS PRESCALE

; ---- ------ ------- --------

; 19200 52 us 13 16

; 9600 104 us 26 16

; 4800 208 us 52 16

; 2400 416 us 104 16

; 1200 832 us 208 16

; 600 1664 us 26 256

; 300 3328 us 52 256

; 150 6656 us 104 256

; 75 13312 us 208 256

;

I think this is for the bit banged serial port but I am reasonably sure they do the same thing on the Atari serial side except only default of 19,200 serial for timer values.

I don't think it is impossible to do with the info I have so far. I should be able to get ATR8K4148 file to compile although I am not sure where to put everything. I am assuming so much, got to be a number of mistakes in my thinking. Like that first sector, no matter what teledisk says is supposed to be 512 bytes of which only 128 bytes are used. I don't think you can format less then a track which means they all have to be the same!

Of course all the labels and what not are different from the Grant's CPM files. Would have been so much simpler to just cut and paste the BIOS section.

I am still confused on how to corner the problem. Thinking moving stuff around and combining files in DEBUG, comparing the SYSTEM.SWP to a known good compile at the right address and doing a file compare to patch the address like James is talking about. I need to spend more time trying and failing and less time thinking.

I almost thought I was going to get a break: DEBUG works on 1.4 meg USB floppies for reading and writing sectors! Down side is the USB floppies don't support anything but 1.4 megs.

[Subby]

 

I have known good bootable ATR-8000 5 1/4" CP/M floppies.

Now the issue going on in this thread is that that you are trying to convert them to images on a PC and the images keep corrupting?

[Kyle22]

Yes, and we also need to turn them back into physical floppies.

[Subby]

OK, that's what I thought.

Let me see if the floppy drive on my 486 works, and you said Teledisk. Any particular version?

[ricortes]

Just a note about that ATR8K4841 source file: Very busted. Didn't notice until I started compiling it, but the tail of the file is just a series of subroutines w/o any code there. Probably just to fool the disassembler but doesn't fool TASM. It could have been working from a broken ATR source.

i.e. last few lines as they appear in the source code.

 

NOP ; F87F 00 .

DEFB '*****************************',CR,LF

DEFB '** CP/M version 2.2 **',CR,LF

DEFB '** for ATR8000 27-April-84 **',CR,LF

DEFB '*****************************',CR,LF

DEFB CR,LF,NULL

Lb0:

Lb5:

Lb7:

Lb45:

Lb46:

Lb47:

Lb48:

Lb49:

Lb59:

Lb69:

Lb70:

Lb71:

Lb73:

Lb74:

Lb132:

Lb135:

Lb136:

Lb137:

Lb144:

Lb208:

Lb209:

Lb210:

Lb417:

Lb418:

Lb454:

Lb495:

Lb497:

Lb515:

Lb517:

Lb521:

Lb525:

Lb528:

Lb529:

Lb530:

[ricortes]

OK, that's what I thought.

Let me see if the floppy drive on my 486 works, and you said Teledisk. Any particular version?

Not to put extra work on you or ask you to do something you aren't familiar with.

 

I would rather have the raw file then a teledisk image. *IF* you want to consider doing that, procedure is to load debug, read maybe the first 30 sectors into memory, then write the memory out as a file. From there anyone should be able to load the binary into memory with debug and write out the first 25 sectors w/o teledisk intervention.

 

Anything is good of course.

[Kyle22]

OK, that's what I thought.

Let me see if the floppy drive on my 486 works, and you said Teledisk. Any particular version?

TeleDisk is funny. The story is that some versions work better on certain disks than others. I wish I had the key to the puzzle.

 

Different versions should be available here: http://www.classiccmp.org/dunfield/img54306/teledisk.htm

[sup8pdct]

I have made a disk with all 512 byte sectors to see if it would work. I comes back with error 4. No idea what it means.

I then assembled a disk with a 128 byte sector 1 and another 9 at 512 byte. Filled it with the correct data ( at least i think i did), after 2 goes at getting it right, i had a booting disk and up poped the cpm text. However, something is wrong, it soon stops working. I have managed to get memtest running, so my ram is ok. Mine will read disks ok but wont format however it seams to write ok??!!??

How i managed this is using teledisk, anadisk, winhex on pc and disk rx on atari. Not sure if i am getting a good boot sector however. Anadisk wont touch it, so forced to use diskrx and atr.

I managed to get my atr mostly working by cleaning off 1 bit of cockaroach leavings on under side of board.

 

James

[sup8pdct]

Messed around some more today. It would appear that to have a booting cpm atr8000 disk, Sector 1 needs to be 128 bytes, the next 9 need to be 512 byte sectors (10 sectors total has to be on the first track). Track 2 is 9 X 512 byte sectors. Wacked out or what??????

 

I have also fixed up the schematic where i have found things that didn't match my board.

 

Things to do is to fix up my ATR to work properly, check disks i made work properly then write some program to make them from scratch.

I would like to get a floppy emulator and give it a go on the ATR as well. Most of that will have to wait till i get a job (wed hopefully) before i can buy some bits. Anyone have some FDC1793 chips laying around?

 

James

atr8000.zip

Edited January 6, 2014 by sup8pdct

[ricortes]

Well brush my teeth and call me smiley. I should spare people the 'Walked to school in the snow, uphill both ways' stories. Last of parts I needed got here so...

 

The good news, what little there is of it, is apparently CP/M uses the same trick as Atari with directory in the center of disk and files filling from the center out. I mostly used teledisk 2.13 and 22disk for hacking around. Teledisk will happy create that nonsense format in the first tracks or at least try. Kept getting ~'that didn't come close to working messages' with some ignore/skip and keep trying options that I took. There's nothing new in two of the disks I looked at, just the standard PIP type stuff and a FC showed them to be identical. Same files as in the big zip that is available. MSDOS absolutely pukes on the images including raw sector reads in DEBUG. 22DISKS, since it goes for the directory and files misses the first track and works for moving files in and out.

 

So here is the ATR8000 Atari BIOS. I haven't sent it through TASM yet but I'll go with what people have said in that CP/M is standard system to system except for the BIOS. Should be able to reconstruct the binaries now.

ATR8KBIO.zip

[sup8pdct]

Actually, the ATR8000 directory starts on track 3, sector 1 (assuming track 1 is first track on disk). The CPM system can be in a different location depending on the system.

Eg. The standard atr cpm system starts at $D400 making it a 60K system (as they call it). The IndusGT CPM starts at $E400 making it a 64K system. One of the ATR8000 disks has the CPM system starting at $D200. Don't know why. The BIOS also moves with the cpm system.

 

The deblock.mac file is the old version sorry to say.

 

I have dissembled the ddsysgen file and am currently working through it. I should be able to change it slightly to write system tracks without cpm loaded first.

This program formats the 1st 2 tracks side zero for the special system tracks format then writes them out and checks them.

 

I have managed to create a bootable (i think) system disk but my ATR is playing up?.

Every time i try teledisk to copy one of my working disks, it doesn't manage to write the 128 byte 1st sector properly (at least on my system) It seams to read it properly tho.

 

 

James

[ricortes]

Track 3 is still far enough from the boot sectors to make it out alive.

 

Not a good reason but maybe a why? DDSYSGEN.COM will generate a new system file with SYSTEM.SWP depending on the parameters you pass it. i.e. DDSYSGEN 0D2 will generate a $D200 version. I think the intent was so you could run CPM on a smaller system like 20k RAM. So some combination of possibilities like SWTP wanted some extra room for BIOS expansion or some good Samaritan generated a disk w/o knowing where to put system files. TBD.

 

Reading up, the major differences between BIOS was detecting density changes and the way sectors were written. New version is better at detecting disk changes and uses alternating heads on reads/writes vs. filling side zero before starting to use side one. I guess what I am trying to say is there exist compatibility going forward to new bios, they can read anything done with old bios. For the single user with their instance of ATR8000, they will still be able to use the system somewhat transparently. A little slower, a little less user friendly, but everything should work.

 

I was hoping I would get lucky but no reason to start now. I've tried DDSYSGEN with the SYSTEM file on a couple of CP/M systems/emulators. None of them are able to do the disk writes or even DDINIT for that matter. I tried doing the suggested ^C from DDSYSGEN and saving with CSAVE 69 CPMATR8K.COM but the file created looks like it is just a copy of DDSYSGEN.

 

I still haven't set up my ATR8000. I think I am ready to start trying to boot some stuff. Knocking on the door anyway. It'll be a real laugh if my ATR8000 is broken!

Edited January 30, 2014 by ricortes

[fibrewire]

I still haven't snagged a SWP device yet - been waiting for you guys to hash out the issues.

 

https://groups.google.com/forum/#!topic/comp.sys.atari.8bit/YwBSEz5Yi8M

 

Steven have been helpful in digging up Corvus material recently - this thread also has a link to some dropbox files that may be valid disk images. In any case, getting these users involved may prove useful.

Edited January 30, 2014 by fibrewire

[sup8pdct]

I am trying to create bootable cpm disks for those that don't have any (like me). DDsysgen has an option to read system tracks. I know where in memory it is stored, so it won't be too hard to make it create system tracks using the ATR's Z command by dumping ddsysgen and system tracks to memory and running from a particular address.

Creating the data area however is a little bit more tricky. Dinit has a couple of calls to the CPM BIOS that sets some drive parameters. Need to work it out some more.

 

Now that i am back at work, I will be able to start looking at getting my atr fixed, But Trouble and Strife is spending all my $$$$$

 

James

[ricortes]

I still haven't snagged a SWP device yet - been waiting for you guys to hash out the issues.

 

https://groups.google.com/forum/#!topic/comp.sys.atari.8bit/YwBSEz5Yi8M

 

Steven have been helpful in digging up Corvus material recently - this thread also has a link to some dropbox files that may be valid disk images. In any case, getting these users involved may prove useful.

"Your powers are weak old man"

I have met the enemy and he is me. Been like 30 years since I did anything Z80 and I was never worth a damn with it anyway.

 

Its just a grinding process now. I think I bought between 70-100 disks to find some good ones. The good news is out of that I have a great batch of 25 1.44 meg 3.5" and maybe 8 fairly pristine 5.25" which should be enough to carry me through. Went through three 5.25" floppy drives before I found one that worked which kind of ate up my supply of 5.25" floppies. Everything else hardware wise was just throwing money at it which is almost fun!

 

Fun is kind of at the heart of the matter. Found the original disk for my Needham PB-10 programmer and the hardware itself. Found my Compaticard floppy controller. Intel box I am using only has one ISA slot so I may have to fix that so I can use both of my hardware treasures.

 

Almost inevitable that we will get something working at this stage, just depends on how close to optimum we can get it. For instance one of boot image I have did something really stupid like first<2?> track is five 1000 byte sectors and the rest of the disk is 512 byte sectors. I think James said ~he found mixed sector size on the same track! That's impossible to do unless the person that made the disk screwed up. The data sheet for the 1793 kind of shows you can only format by track. I'm still not sure what the standard format for the ATR8000 should be since in their lit they show they support everything from 128 to 1,024 bytes per sector.

 

Now it could be a good idea to make a 128 byte/sector CP/M boot disk. That way you could convert it to an .ATR to distribute and could make a copy with stock 810/1050. It could be a good idea to make a 512 byte/sector disk so it would be compatible with Intel boxes. It could be a good idea to make a 1,024 byte/sector disk is that is what the original ATR wanted. I really don't know but lean towards the 512 byte/sector at the moment.

 

Still doing detective work that may not even be necessary if James plan of attack works out to be quicker. I'm guessing that BIOS source was done with a linking assembler, TASM pukes on it anyway. Main thing for me is it shows MONITOR entry points at $F000 so I have a better idea of what is going on.

 

And what the heck is a ATR8000 Z command?

[ricortes]

I am trying to create bootable cpm disks for those that don't have any (like me). DDsysgen has an option to read system tracks. I know where in memory it is stored, so it won't be too hard to make it create system tracks using the ATR's Z command by dumping ddsysgen and system tracks to memory and running from a particular address.

Creating the data area however is a little bit more tricky. Dinit has a couple of calls to the CPM BIOS that sets some drive parameters. Need to work it out some more.

 

Now that i am back at work, I will be able to start looking at getting my atr fixed, But Trouble and Strife is spending all my $$$$$

 

James

OK, probably will distract you more then help. I went back and looked hard at that CSAVE I made and what it looks like is it stored the DDSYSGEN program AND the relocated SYSTEM.SWP file! Ready to write out I hope but I think it will only write on a true ATR8000 because of calls to the monitor/hardware specific. Also you have to allow for my ability to screw up. I'm pretty sure I relocated it to $D400 but I see in the ATR8000 ROM listing I maybe hadda oughta put it at $D200.

 

I'll attach it so you can take a peek at it if you wish. Using MS DOS debug, the file starts at $100 naturally with the DDSYSGEN but at $1900 what looks to be the CPM 2.2 file starts. Not sure if you are familiar with DEBUG, but I'm guessing you will have something to look at the file with. You can even use The Joyful Coder's Memopad with the offset to CPM at $1800.

 

I may not get to it today as I have another one of them busy days that get in the way. I'll just load the file into DEBUG on my work computer and write out memory from $1900 to a MS DOS formatted disk and see if it boots on an ATR.

 

Rick

CSAV69.ZIP

[tschak909]

That's just it...The ATR8000's firmware and controller combo supported just about every damned variation of MFM and System/34 format under the sun, I always formatted disks under its CP/M as Double Sided / Double Density @ 1024 bytes a sector.

 

-Thom

[ricortes]

Taken from a OCR file. Spent quite a bit of time changing o's to 0's and CHD to CMD. I don't have my ATR set up yet but I thought someone may want to take a look at it/test it in the meantime. There has to be more bugs I can't catch yet. No harm, no foul, I know people are probably more strapped for time then me. Anyway, I didn't know the ATR worked as a Z device before James mentioned it. Apparently most of the manuals including mine didn't have this in them. So yes, in theory you could load CPM from and Atari. Just use the Z handler to fill the ATR memory with what is supposed to be there and you should be able to execute it. Use a period '. to get back to the main loop and hit reset to exit.

 

100 REM <<ATRMON.BAS>>

110 REM <<D=DUMP MEN>>

120 REM <<M=EXAMINE MEM>>

130 REM <<G=EXECUTE AT ADD>>

140 DIM X$(16)

150 X$="0123456789ABCDEF"

160 DIM C$(1)

170 DIM BUF$(256)

180 DIM H$(5)

190 REM SET UP USR Z

200 Z=ADR(" ")

210 DATA 104,76,89,228

220 FOR I=0 TO 3

230 READ X

240 POKE Z+I,X

250 NEXT I

260 REM PRESET DCB BUFFER

270 DCB=768

280 CMD=770:REM "R","W","G","S"

290 AX1=778:REM BYTE COUNT OR LOW ADD

300 AX2=779:REM HIGH ADD

310 DIR=771:REM SIO CONTROL

315 NUM=776:REM BYTE COUNT FOR SIO

320 IN=64:REM INPUT TO BUFFER

330 OUTB=128:REM OUTPUT WITH BUFPER

340 OUT=0:REM OUTPUT WITHOUT BUFFER

350 DATA 90,1,0,0,0,0,1,0,0,0,0,0

360 REM "Z"=90,DEVICE ID.

370 FOR I=0 TO 11

380 READ X

390 POKE DCB+I,X

400 NEXT I

410 REM SET UP BUFFER ADDRESS

420 A=ADR(BUF$)

430 X=INT(A/256)

440 POKE DCB+5,X

450 POKE DCB+4,A-X*256

460 INPUT H$

462 C$=H$(1,1)

465 H$=H$(2,LEN(H$))

470 IF ASC(C$)=ASC("D") THEN 600

480 IF ASC(C$)=ASC("M") THEN 1000

490 IF ASC(C$)=ASC("G") THEN 1500

500 GOTO 460

600 REM DUMP MEMORY

610 GOSUB 2000

620 GOSUB 5000

680 POKE CMD,ASC("R")

690 POKE DIR,IN

700 POKE AX1,128

705 POKE NUM,128

710 GOSUB 9000

720 N=0

725 H=D

730 FOR I=0 TO 127

740 IF N>O THEN 760

745 D=M+I

747 GOSUB 4000

748 PRINT H$;

749 PRINT " ";

750 N=8

760 D=PEEK(A+I)

770 GOSUB 4000

780 PRINT H$(3,4);

790 PRINT " ";

800 N=N-1

801 IF I>0 THEN 820

802 FOR F=7 TO 0 STEP -1

803 G=PEEK((A+I)-F)

804 IF G<32 THEN 808

805 IF G>121 THEN 808

806 PRINT CHR$(G);

807 GOTO 809

808 PRINT ".";

809 NEXT F

815 PRINT

820 NEXT I

830 GOTO 460

1000 PRINT H$;

1010 PRINT " ";

1020 GOSUB 2000

1030 GOSUB 5000

1035 M=D

1040 POKE CMD,ASC("R")

1050 POKE DIR,IN

1060 POKE AX1,1

1065 POKE NUN,1

1070 GOSUB 9000

1080 D=PEEK(A)

1090 GOSUB 4000

1100 PRINT H$(3,4);

1110 INPUT H$

1120 IF ASC(H$)=ASC(".") THEN 460

1130 IF LEN(H$)=0 THEN 1190

1140 GOSUB 2000

1150 POKE A,D

1160 POKE CMD,ASC("W")

1170 POKE DIR,OUTB

1180 GOSUB 9000

1190 M=M+1

1200 D=N

1210 GOSUB 5000

1220 GOSUB 4000

1230 PRINT H$;

1240 PRINT " ";

1250 GOTO 1040

1500 PRINT H$

1510 GOSUB 2000

1520 GOSUB 5000

1530 POKE CMD,ASC("G")

1540 POKE DIR,OUT

1550 GOSUB 9000

1560 GOTO 460

2000 IF LEN(H$)<1 OR LEN(H$)>4 THEN 2099

2010 D=0

2020 FOR J=1 TO LEN(H$)

2030 K=ASC(H$(J,J))-ASC("0")

2040 IF K<0 THEN 2099

2050 IF K<10 THEN 2090

2060 K=K-7

2070 IF K<10 THEN 2099

2080 IF K>15 THEN 2099

2090 D=(D*16)+K

2095 NEXT J

2096 RETURN

2099 PRINT "INVALID HEX DATA"

2100 RETURN

4000 FOR J=4 TO 1 STEP -1

4010 K=D

4020 D=INT(D/16)

4030 H$(J,J)=X$(K-(D*16)+1)

4040 NEXT J

4050 RETURN

5000 Y=INT(D/256)

5010 POKE AX2,Y

5020 POKE AX1,D-Y*256

5030 POKE CMD,ASC("S")

5040 POKE DIR,OUT

5050 GOSUB 9000

5060 RETURN

9000 X=USR(Z)

9010 RETURN

[sup8pdct]

OK, probably will distract you more then help. I went back and looked hard at that CSAVE I made and what it looks like is it stored the DDSYSGEN program AND the relocated SYSTEM.SWP file! Ready to write out I hope but I think it will only write on a true ATR8000 because of calls to the monitor/hardware specific. Also you have to allow for my ability to screw up. I'm pretty sure I relocated it to $D400 but I see in the ATR8000 ROM listing I maybe hadda oughta put it at $D200.

 

I'll attach it so you can take a peek at it if you wish. Using MS DOS debug, the file starts at $100 naturally with the DDSYSGEN but at $1900 what looks to be the CPM 2.2 file starts. Not sure if you are familiar with DEBUG, but I'm guessing you will have something to look at the file with. You can even use The Joyful Coder's Memopad with the offset to CPM at $1800.

 

I may not get to it today as I have another one of them busy days that get in the way. I'll just load the file into DEBUG on my work computer and write out memory from $1900 to a MS DOS formatted disk and see if it boots on an ATR.

 

Rick

According to the docs. $D400 is the normal ATR CPM system start address. The $D200 is a special one (why?) I have winhex so looking and comparing is a doddle for me.

I will look at your file when time permits,

 

James

[Subby]

While I seemed to have dropped the ball earlier, this time though...

 

If anybody is in Atlanta this coming weekend and wants 5 1/4" ATR8000 CP/M diskettes copied, bring some and stop by my display at VCFSE.

Oh, did I mention I have my 8" floppy drive working? I guess we'll have to figure out how to make bootable 8" diskettes.