Jump to content

1050's Photo


Member Since 24 May 2007
OFFLINE Last Active Today, 12:52 AM

#4152087 Down loaded ARC files...

Posted by 1050 on Wed Nov 7, 2018 1:19 AM

While I prefer MS-DOS on win98 using the original
System Enhancement Associates ARC 5.0 which is
exactly what Puff's SuperARC and SuperUNARC are based

But caution is advised - this is the very program that
would hound Phil Katz to his untimely end and very
first flame war to end all flame wars. Posting it
would then be against copyright law even if no-one
cares anymore. I used to post a link to it but the
University of Texas apparently had better use of the
server space that used to host it. It's gone now.
But the curse lives on:
"If you fail to abide by the terms of this license,
then your conscience will haunt you for the rest
of your life."

It will do both ways perfect every time, but you
missed your chance unless you can find it on your
own now.
  • jhd likes this

#4145426 130XE Reverse Option Key for Basic

Posted by 1050 on Mon Oct 29, 2018 4:59 PM

My theory is that the extended hang time for memory
on the 4464 equipped devices is the better silicon
used in those. Just keeps the memory cells at their
proper level of charge very much longer. And no work
around exists that I know of. So Mathy asked if there
was a software solution when I was writing MyRD code.
So I put in a keypress combo that will 'bomb' the
box and force a coldstart no matter what.

To do this fastest one does a RUN AT E477 and then
press SHIFT + 1 when the RUN AT screen goes away. It
will reboot twice, with the second one being the wipe
out bombed coldstart deal.

Since those times some of the newer toys also have a
software solution built into them and I would think
they are the better way to deal with this issue. Not
sure my method is foolproof since it must boot DOS
again in order to run the MyRD autorun.sys file too.
But it was the only stick I had so I used it. Just
for grins you might try it out?

#4137758 800XL U20 IC shows most pins low

Posted by 1050 on Fri Oct 19, 2018 9:17 PM

My suspicion is ANTIC U7, so I wonder if you get any
pulsing from pin 29 /REF signal. The MMU is using that
as a clock input and thus the entire machine is
dependent on it. ANTIC is actually the only chip that
doesn't need a chip select signal (derived from MMU)
because it's the one running the show. Check also for
pulse on pin 7 ANTIC U7 another very important clock.
Although ANTIC isn't the source for that one, it does
create the /REF signal however. If that is absent and
pin 7 has steady pulsing, it doesn't look good for ANTIC
in my opinion.

I've been wrong before though, and you can expect many
other opinions as well, each of us looking for the
quickest way to prove their hunch in turn is all this
amounts to now until someone stumbles upon something
significant that clearly gives a direction to proceed

#4133778 1050 ROMs

Posted by 1050 on Mon Oct 15, 2018 1:00 AM

Gentlemen, thank you.  This comedy of errors has all been worth the price of admission.

Interesting having you on board as well. Curious as
to the term you use as checksum salt though. Haven't
run into it before and wondering if the salt part of
it is an acronym perhaps? Pray tell what is it if so?

You seem to have discovered the location for the checksum
storage correctly too. I was disappointed to learn that
my hex editor's choice of checksum generation was so
lacking in it's description and/or methods used. The
internet was of no or little help either but by shear
luck I figured out a way to get to where I wanted to
be in the first place.

My choices include something called checksum-8 which
I assumed was it. I was wrong, that is only the right
portion of an uncompounded add. Truncated if you will.
checksum-16 adds two more digits to the left of the
same two right side digits. Checksum-32 gives more
digits to the left even further.

If you take those digits and add them to a total add
then and only then do you get the accumulated add as
done by the rolling over with carry of the A register
by relentless ADC operations - which is what I wanted.
In other words what you achieved with your C snippet
which to me is for study only since I have no idea
how to make that work for me. I do have your listed
results but I was not getting the same results until
I ran BUG/65 in an emulator using this code typed in


rev-J.rom was loaded to 0x7000 by the emulator monitor
previously and
G6000 @6015
was entered into BUG/65 to get 29h sitting in reg A.
Other attempts weren't necessary after I found out
how to work with checksum-32 results moar better than
the internet could describe it to me. That came as
a result when I selected all the checksums at once and
noticed that the 8 version was just the truncated form
of all those higher and they were truncated in turn as

Oh, so those are not rolled over with carry... And the
light came on.

Further studies into the BRK instruction show that it's
related to power up, RESET, and NMI vectors and
behavior as well. Except the B flag is set and pushed
after the PC is pushed and the vector loaded and ran is

Well sir, that is the blink forever more with the busy
light routine and that clearly NEVER happens with Atari
1050 code unless there is a defective chip in the works
somewhere. So something is odd somewhere with BRK
command or the way it is meant to be used.

I found this on the BRK instruction to notice that our
own Rybags commented on that page.

This is by far more information on the BRK instruction
than I have ever seen before and yet there are also
wrong info given elsewhere. Looking over Rockwell
information I see that NMOS version ignores BRK
vector and CMOS 65Cxx version uses it instead.

So it never was a thing for us to be able to use.
Atari sure wrote a lot of code for a neutered instruction.
And different code could be made to same effect but they
didn't do that either. Very curious situation.

#4129508 Some web sites have power pins of GTIA reversed

Posted by 1050 on Mon Oct 8, 2018 10:28 AM

Problem may stem from the Atari 800XL FSM schematic which
has pin 3 with a label of VCC but is properly diagramed
as connected to ground. Pin 27 suffers the same fate
as incorrectly labeled as VSS but is properly
connected to +5 by diagram.

If someone went by just this official diagram that
has the mixed up labels on it things could go bad in
a hurry.

And a lot of people do just that without checking too.
Atari made a mistake here and everybody else just
follows suite without confirming that the labels are
wrong polarity for those functions.

#4127820 1050 ROMs

Posted by 1050 on Fri Oct 5, 2018 11:40 AM

I'm with Candle's take on the AND #$7F deal, it must
be a typo for AND #$F7. But why did they think that
needed changing? Mysterious.

Other fixes may or may not be worthy as well?

And I've never tried the FLOPOS.ROM file in a real
1050 - it may not work at all. Just as Candle states.

The last 5 of the 9 fixes are wrong move at wrong
time deals. Team Pascher/Derks must have been burnt
out to a slightly crispy level at that point? They
did a brilliant job of commenting somebody else's

What we do know is that the Atari code works, so
somehow the BRK command must be falling thru and
has no effect for setting an ERROR condition as it
is used for in many other places within this code.

Because of the wasted floundering about in post #56
there is room for a real jump to busy light flashing
routine, along with checksum corrector byte for a
zero checksum result too. Interesting possibilities
exist to learn a bit more about the BRK bug among
other twists.

For kheller2 and others here is a mads version of
Pascher/Derks version of FLOPOS made from Candle's
K version file. Changes from K version will be found
by searching for ;** comments made by me to note the 9
changes from K version. I don't use mads so it's a shot
in the dark from here. Good luck with it.

Attached File  flopos_asm.zip   14.8KB   13 downloads

Don't forget kheller2, mac/65 will use file segments
always and the output then must always be stripped of
those - say 68 extra bytes worth? First clue is the
first header, it should be FF FF 00 F0 FF FF and if
it isn't that then there are extra segments within the

#4126058 800XL Custom ROM Questions

Posted by 1050 on Tue Oct 2, 2018 8:08 PM

He is looking for an autoboot method where he does
nothing but boot the atr.

I made one from CHKROM.COM found on your atr and it
does work here. Made with AtrUtil it is of course
a KBOOT disk, notice the flash of K in the corner
for Ken Siders RIP.

Attached File  CHKROM.atr   5.77KB   6 downloads

#4114509 CO 60472 U29 Atari 800XL

Posted by 1050 on Sun Sep 16, 2018 3:55 AM

Quick comment, perhaps could lead on to something else. All D lines from D0 to D7 are High instead of Pulse...accross the boad U4, U5, Pokey, etc.....
Is this significant? Or could it be a symptom/confirm from bad U5 ROM, U29 or U30.? Assuming antic,gtia, cpu worked fine on a atari 5200 test. Ram is all new ics, mutiplexer are new as well.

R23-30 on the 800XL pull the data lines high so it's
not unusual to see that unless you were expecting data.

How can a machine function if it's not using data?
It can't.

Without a working U29 you have no ram or even stack
for the CPU. The CPU is likely stuck doing something
internal forevermore?

Best is probably the only one that stocks it, so outside
of killing other Atari for it there is the below circuit
that is supposed to be the equivalent. I got this from
across the pond from a site where they don't speak


And I didn't save the url for it either so you could
find it today. At any rate it is using one 74LS14 Hex
Inverter with Schmitt Trigger Inputs plus a handful of
discrete parts such as resistors and capacitors to
generate time delayed signals that purportedly work
as well as the stock U29. I've never built it so I've
never tested it to see if it does work. I can see that
it does have potential too or I never would have saved


Only thing wrong with your swap it method is the lack
of a full complement of ammo to work with. It is the
fastest way to find a faulty IC that there is. And
almost anybody can do it.

#4110746 RGB availablity inside the original 8-bit motherboards?

Posted by 1050 on Tue Sep 11, 2018 1:26 AM

From what I know they actually make RBG, luminance,
and sync first then marry it all into color phase
encoding. Those signals being GTIA's LUM0-3 respectively,
perhaps. Just a suspicion mind you - no facts can be
proven by me anyway. Somebody with moar better setup
might be able to smell around in there though.

I've seen a lot of TV circuits that take RGB with
sync and run it thru the 'double down' resistor
network scheme as in R47-50 to do the TV signal
generation with. Each resistor in that network is
half the value of what the previous one is for a
precise reason you see. What people can't fathom
is that within the following transistor's gain
function, FM modulation occurs with the color
phase signal and the results are the perfect marriage
made for TV use. Again can't prove it by me, to twist
a phrase.

Not a high priority issues that I will ever defend
either. You can think what you want over there just
as I'm going to do over here. rant/OFF

#4109658 Atari 800 XL black screen

Posted by 1050 on Sun Sep 9, 2018 5:47 PM

Hardware is not my area of expertise, but my understanding is that the ANTIC/CTIA/GTIA gets primary control over the bus and it is the device which has the authority (via hardware) to tell the 6502 to yield for this clock cycle, not the other way around. A high NMI pin on the 6502 seems to tell me that the ANTIC/GTIA is not releasing the CPU to access the system bus (including memory). Is my understanding correct?

My logic comes from the way code works entirely. The
CPU sets the NMI capabilities in an ANTIC register.

But brain fart time - this is not the NMI line itself.
Which runs between GTIA and the CPU only.
Many other mistakes I assumed wrong as well.
Because I was stuck in the wrong place, I was not seeing
the entire picture. Which is why it's best to have
several people looking as someone in the group is
bound to have a better take on what just happened.

Well done jmccorm.

My comment on this line:
U7 NIM bar, U23 CS2bar and U17 SO, SI, S2 bar still wrong.

The nomeclature in the schematics show them with a bar above the name of the signal, I think it means signal was inverted or flipped. Apologies for my lack of correct naming.

Ahh, thanks for that clarity. The bar is important
for determining active signal polarity. It represents
a negative polarity as the active state or signal
asserted state.

So a high /NMI would mean a Non Maskable Interrupt is
not being used.
/FORWARD SLASH can be used to type it on systems that
can't do bar over label. A standard label as typed
in uppercase then would be a positive asserted logic.

Not the top level hardware man myself, I can only
suggest that the /NMI line is used to tell the CPU
to get off the pot because the big boys need to use
it asap. And this is backwards to what I suggested
before as to who tells who what.

Logic probe = useful (in the right hands)

#4107474 Attempting to repair a 1050 Disk Drive-no activity light no motor/head spin

Posted by 1050 on Thu Sep 6, 2018 8:57 PM

There is an issue with some OS chips that are coded
for a different stepper motor timing that may be at
fault for the stepper motor error showing up. Wrong
OS could easily not be accounted for in the source
code for the test disk.

A nebulous place for certain, but a reminder that all
is not perfect under the Atari umbrella. End of the day,
it works flawlessly, there may be nothing that can
be done anyway. Outside of extensive code examination
and most of us have something better or more fun to
do than that.

IIRC, the code for the 1050 OS was found to contain
some self test errors and a corrected version supplied
by a couple of germans long ago. You might want to go
there and get a new OS rom burnt with the corrected
code to test again?

The self testing sections begin at FAC4 in the
a8_print_tmp3.txt which is the assembly report of
that project.

#4106015 Panasonic Matsushita JU-475-3 AKJ floppy drive

Posted by 1050 on Wed Sep 5, 2018 2:07 AM


All that remains of a vast sea of confusion when it
was current. It is no longer current and should be
taken with a very large grain of salt.

I agree with BillC, it's a 1.2 meg drive.

Not suitable for XF-551. At best it might be able
to read a 360K disk but will write to it with half
width heads. Rumors do exist that these are usable
with some systems, but I would not go there unless
I was prepared for frustration and utter failure,
not having any other choice as well.

#4102041 1050 drive issue

Posted by 1050 on Thu Aug 30, 2018 7:13 AM

In the world of Atari DOSes there are two main
categories, SpartaDOS file system and Type 2.0 file
system. That is usually denoted as DOS 2.0 type and/or
as just AtariDOS as well. Several DOS including MyDOS
are DOS 2.0 type. TOP DOS supports DD and is a Type
2.0 DOS which really only means that you take a real
DOS 2.0 disk with files on it and any type 2.0 DOS
can see them, find them and move them. (with tiresome
exceptions) Happy DOS should be another DD contender
but the list for DD type 2.0 is a rather short list,
I'm already drawing blanks at this point. Wiki has a
better memory.

So on the SpartaDOS type side there is of course SDX,
and SpartaDOS 1x, 2x, 3x and BW-DOS. IIRC and I often
don't RC when it comes to Sparta issues.

DOS 2.0 only did single density, some have modified
it, but more modified DOS 2.5 too.
Only the never released DOS 2.0D supported full
double density where DOS 2.5 supported Single and
Enhanced density. ED is also called dual density
with a few lazy thinkers dropping back onto using
the word double on occasion. I believe Bob Wolley
hacked a version and got Double Density for
DOS 2.0 but the details were not remembered here.


Can you please lay out which is the best and why in descending order? Is the communication / sio timing tailored more for pal or ntsc these days?

I honestly think 4.55 beta 4 is the best and certainly
the least buggy. Bugs are fixed as stumbled across with
an option to report a bug at Mathy's MyDOS page. It's
almost always a Marslett bug since Puff wrote his
comments on bug fixes in lower case in the source
code. In the early days both I and Mathy had MyDOS
system up and running and working the devil out them
so bugs found were common. Today neither of us has
a real system and what bugs I come across are rare
since I'm not caged by an 8 bit anymore. There should
be a bug list of fixed bugs at Mathy's MyDOS page or
an early try at a one.

Don't use 4.53 or 4.54 outright.
This could certainly have been most of your problems too.
It's still quite popular.
The problem here is that there are repeated sections
of DOS.SYS code and no known resolution to the issue
where DUP.SYS knows where to call a routine at. Is it
jumping into the portion that was displaced by the
duplicate block of code or not? I can not know since
the source doesn't work for these two versions. I
would have to disassemble it entirely and might as
well fix it for what? I can't keep a decent timeline
on 4.55 beta 4 needs as is = not happening unless
anybody else wants to fix it. I can't declare
permission to do so anyway, I just work on my version
when I feel it needs it bad.

4.50 is the original and for most people few problems
actually exist in day to day use. But you want to use some
features of MyDOS that are slightly out of the norm
and a darn bug pops up. I've got most of them corralled
I hope but often when you are using some new hardware that
I don't even have, it can lead to issues.

Nothing has been done with PAL/SIO timings, MyDOS still
doesn't support high speed SIO in the normal manner of
the meaning. You can have it with Hias's high speed patch
for your OS however and it should work fine too. Don't
blame MyDOS for code it doesn't have, if there are high
speed SIO issues using MyDOS, know going in that MyDOS
does nothing under ROM and has no inherent dealings
with SIO routines other than standardized OS entry points.
If you feel it's still a MyDOS problem, I'm all ears.
Please splain the issue to me. PM or out here in front
of everyone. Often in front of everyone is where I see
the real issue explained well, and there are issues.
Like FJC's fix for 65816 machines running MyDOS which
seems to just work, where unpatched MyDOS fails with
a 65816 running the code. Jon's 65816 patch is likely
to be included in a beta 5 release with full credit
attributed to him with a link to his website in the
source code for that beta 5 release as is the normal
way I steal code for MyDOS. Jon's credit would be the
first website since all other victims don't have a
working presence on the interwebs.

In my opinion there are two versions to use 4.50
and 4.55 beta 4. I have fixed some bugs in 4.55 beta
4, while including all of David's (author of 4.53/4)
brilliant add ons within beta 4. You are on your own
with 4.50. Unless it's as easy as Jon's 65816 patch
kind of a deal.

Companion software MyRD is used as either an
autorun.sys for 4.50 or *.AR0 file for beta 4
to set up a ramdisk and load it with files from
D1:RAMDISK: subdirectory. Source and file at
Mathy's MyDOS page.

All MyDOS has an issue we call the format bug where
MyDOS steadfastly returns to prior configurations
for a drive after proper setting of the configurable
drive via percom block methods. In MyDOS the percom
block is just ignored and the old data is restored
every time you go there. This can lead to issues not
so very clear especially coupled with modern hardware
that expects a different result than outright refusal
to play fair. The percom block method in MyDOS is
completely broken, no errors reported either.

Only workaround currently is to use (O. Change Config.
method from DUP.SYS menu where a change can be made
and it's now a valid change. Machine language shorcut
of just stabbing proper values into both SECSIZ
(0x07C4) and DRVDEF (0x07CC) tables will work too,
but these values are 'encoded' in MyDOS style
shorthand so it's not entirely intuitive what values
are needed here. I was tasked with writing a format
program for MyDOS where I would do this latter part,
but I don't have a working 1.44 meg percom block to
extract valid values from so a bit reluctant to
issue 2, 3, or 4 versions based on trial and error
alone. Anybody with a working 1.44 meg drive care
to share the percom block from it? Post it here or
PM me. Progress has been made concerning the 800XL
under ROM Ramdisk, just have to find room for the
code from DOS 2.5 version and make it fly with
MyDOS. All the news fit to print from MyDOS currently.
So back on topic requires a new thread or PM shall

#4101897 Atari 800 XL burning power adapters

Posted by 1050 on Wed Aug 29, 2018 9:41 PM

Keep your money guys, use it to buy needed stuff with.

Like a voltmeter. Be sure to test it without the computer
connected first. You are looking for 5 volts where 7 or
so means the power supply is a RAM killing machine. Check
both power supplies or all you have for that matter.
Connect good 5 volt supply to computer and turn it on to
measure again, you still need 5 volts and if you don't
have it then the computer is drawing too many amps.
To be continued...

Move your #3 coil to an easy to work on spot and move that
coil to #3 spot. Start it up, if the miss follows the
coil, buy a new coil. If it stays on #3 buy a spark
plug and spark plugs wires if that is applicable in your
particular case. Still no joy you need to do a compression
test on #3, today's engines should be over 100 PSI with
185 being near new condition. To be continued...

#4098018 Second XEGS Repair

Posted by 1050 on Thu Aug 23, 2018 9:00 PM

GTIA pin 17 will make 12 volt (IIRC) so if that's it
then nothing to really worry about there. Phase 1 clock
is voltage doubler pumped to provide that signal and
it is required. You sure you are not on AC voltage

Doesn't that indicate that they're working?

You are certainly assuming wrong, logic probe tells us
there is activity but not if that is going in or
coming out or what it should be. If you had a dead ROM
I would hope all the support chips would be trying to
talk to it in an effort to wake it up. Dead doesn't
mean all signals enter the twilight zone and cease to
exist, it means instead they are mostly ignored by the
vacant party of concern.

These XEGS ROMs are known to lay right down and die.
You can only prove a positive by swapping with a known
good ROM and that doesn't fix it outright.

I don't believe STELLA is a chip found here. Please call
it GTIA if you meant GTIA instead.

XL/XE schematics are almost identical as to device number.
C42 is circled but I can't find it in XL/XE nor do I
know if XEGS schematic number match XL/XE scheme as tightly
as does XL to XE. Atarimania does not have XEGS in
SAMS which means all we have is Sobola Schematic, is that