Jump to content

1050's Photo


Member Since 24 May 2007
OFFLINE Last Active Today, 6:12 PM

#3997207 How to load SRC files?

Posted by 1050 on Fri Mar 30, 2018 6:58 PM

End of the day this atr is just an obligation fulfilled,
Hofacker said the book came with a disk and this is the
disk, so now you can go fish or any other thing. But
what you can't do is take Hofacker to court since the
book came with a disk as advertised.

No matter it is using some unknown word processor to
make the text .src files with that are not the usual
fare today and this needs converting to more standard
flavor for general consumption to start with.

Then there is assembler used which is unnamed in the
source code as well. Each line starts with OUT LN for
example which I take to be a Line Number routine which
is not included that I could note while I did the above
conversion to ascii so we all could see the forest for
the trees.

My take on it is horribly done with no include hints or
useful source other than it qualifies legally as source
code perhaps. I would have to replace many items if I
were to translate this source code over to MAC/65 and
at the end of the day I have saved 2 minutes using this
stuff as the starting point where it could take all day
to come up with something that works. IF I knew what that
was in the first place, and I don't.

At any rate the translated source files are zipped below
as .txt files readable on the PC. To use these with an
Atari you'll need to further translate 0D0A pair for
Atari 9Bh linefeed character and there are many programs
for doing this that run on the PC at least. They used 09h
for TAB character so I replaced those with 5 space
characters just because it makes my life easier to do it
that way. Some programs want to vomit when they hit 09h
TAB character and I have little patience when it comes to
cleaning up vomit.

So not very useful information on the disk, perhaps some
of the BASIC programs are where these were meant to be
used? NOT going there because this is really your job.
I find the files to be mostly fluff and filler, to be
ignored for the most part.

Attached File  Hofa.zip   5.7KB   16 downloads

#3990885 1050 ROMs

Posted by 1050 on Wed Mar 21, 2018 8:43 PM

Confirmed MD5 identical to assembled FLOPOS source
code project found in that same folder at pigwa.

#3972508 One Last EPROM

Posted by 1050 on Mon Feb 26, 2018 1:21 AM

D9: works on MyDOS but only as a ramdisk set up to
be that number. You don't get it shown on the menu
either, but it's there just the same. The ramdisk
driver of MyDOS cheats the SIO such that there is
never a call to SIO code for ramdisk work anyway.
And this why VTOCFIX doesn't work on the ramdisk
no matter what number it is.

Nicely done there. Will put that one in the memory
banks for sure.

#3972485 Is there a 14K ramdisk for XE/XL which works under MyDOS?

Posted by 1050 on Mon Feb 26, 2018 12:21 AM

Two questions:

  • Are you aware that the Highspeed IO patch (loaded as binary, not as a ROM) stopped working with MyDOS 4.55b4? Is this a concern for you?
  • I may have missed it. Was there a changelog for 4.55b4? I'm having trouble figuring out what the new features/fixes are.

1) Nope, but then we get zero feedback so how could I know?
I'll look into the why of fail on this, Hias has some of
the best code out there and this situation will not be
allowed to remain broken.
Of course it's a concern, she's my baby. And also of
course that doesn't mean you need my permission
to fiddle with it or release a version of your own.
Just follow Marslett's public domain release directives
in the source code which are include source and it
would be handy to know just looking at it, that its
your version.

2) Changelog is within the source code in a haphazard
manner. Puff comments in lower case, mine also but with
* starting them to denote it's me. Original was upper
case and appears to be only Marslett but sometimes
it's not real obvious which of Puff or Marslett it
really is.

Haphazard part is where sometimes I'm not very consistent
with altering last version info and/or marking new
version comments. Trying to keep track as in the use
of an actual changelog as normally used wasn't within
my capabilities when we started down this road so
putting it all within the source code seemed to be
a better idea at the time.

So searching for ;*space should find every one
of my comments as a take away main point.
Every bug found should be called out with it's
own comment naming the bug too.

Along the lines of the sentiment expressed above, I'd like to start the boot process with something entertaining, and not a static text-mode display with some disk loading time.

  • What would be involved in running my own custom binary before MyDOS loads (the DOS part, not the DUP part) and then having it continue with a normal DOS boot?

Quite a bit I'm afraid. First off I/O on the atari is
done with critical flag set so no screen updates are
allowed during disk activity. You'll have to implement
those within your loading code for screen updates to
remain 'live' looking at the very least.

So normally one only boots once thru the OS code, we
can't have two boot sectors either. That can be worked
around by having the boot disk load your entertainment
code, start that, and continue with the boot which
does a raw data load of DOS.SYS as a modified data
store section of raw sectors and then that can be
started at any time with
JSR 0x07E0 ; Same as DOSINI but it's not loaded yet so absolute address used.
JMP (0A) ; DOSVEC, dosini run loads DOSVEC, DOSVEC run loads DOSINI - cute huh?

Then MyRD2 would load, and run along with any other .ARx
files. DUP.SYS screen is not necessarily the end, you
can go where you want to by several means at that point.

Some things already out of step from your proposal
such as using under ROM ramdisk for screen data
before MyRD2 has had a chance to format it. You could
put your entertainment/boot loader code at 0x2000 and
while it runs, then load the DOS.SYS information at
0x0700 with modified memlo pointer to the end of
entertainment code so that MyDOS doesn't step on it
while doing ramdisk I/O, later then corrected memlo is
restored after extensive memory use is over and the
entertainment is no longer wanted.

This sort of defeats the need for under ROM ramdisk
except to store DUP.SYS there, but that's not a bad
thing either way. Any way this can make sense of what
you want happening when you want it can still be
possible, I'm thinking.

As I mentioned, I didn't mean to summon you here and now. I was going to hit you up on these issues a little bit later. I do appreciate your time and your effort on preserving everything around MyDOS and improving upon it.

As long as I can still say this with a smile :), we
appreciate in return any such bug reports as you
have provided here.


Well, I did go back to MyDOS 4.55 B3, because with B4 the MyRD2 did not work for me any longer (no clue why). With B3 it works as it should...

Sorry to hear about that.

Last I knew you reported a problem where large files were not
being loaded with MyRD2 and that was the issue.

Fixed that with a found Marslett bug and re-issued MyRD2 at
Mathy's MyDOS page. So as far as I knew, it was all fixed
and everybody was happy. Especially the very guy I did
the fix for.

For everybody, please get and use the latest files from
Mathy's MyDOS page. That way we are all on the same page.

So we have two instances where B4 is reported as broken and
what I have here is an odd situation of having a different B4
in my emulators as that what is found on Mathy's site as B4.
I always assumed my 'in house' copies were somehow stepped on
by some intermediary 'test' assemble done here that was not
documented very well at the very least.
But it's possible that Mathy is hosting a virus version thru
no fault of his own of course. Long ago there were issues
of broken arc files of earlier versions of MyDOS and
this was caused by his Mac and it's zip program somehow
IIRC. I have checked many times his B4 offering there
and it seems to pass muster each time. But I'll do
it again.

Could be it's broken there, so I'll go get that B4 version
and attempt to use it to see what problems I run into. I'll
also re-assemble from my source code and the source listed
there to double check things from this end that way.

Changing versions with MyDOS is problematic to say the least.
It requires doing H. Save DOS back to boot disk for one,
which if you are out of practice can be a YUGE
stumbling block in getting the new version to actually
be the new version. And confusion all too easily can set
in at that point. Which is why I've changed the distribution
method from the old way of supplying .obj and build files
to ATR since we seem to be in an age where ATR makes more
sense and is easier to use. For me, I'm stuck doing it
the build method, no reason to foist that burden upon
the masses.

Back to topic:
Instead of using a XL-Ramdisk on 64k computers (which requires some kind of VTOC and DIr), why not simply using the RAM under the OS (in-)directly from within a file ? Even when you use a DOS 2.x filesystem you can use the RAM under the OS by e.g. loading a file into normal memory and then moving part or all of it to RAM under OS. Then there is no need for an additional VTOC and Dir. which also wastes some sectors on your small XL-ramdisk. (Usually from the 14k available there is only 12-13k usable, so 1k or 2k are lost.)

As a side note, the under ROM ramdisk would not be using the
extra 8K afforded by BASIC if the machine were booted with
BASIC off. Stands to reason I hope that we can't use that
area for a ramdisk if it is being used for screen display
ram as would be the case in most instances. So this extra
ramdisk space with BASIC on only would then have to be
written into the 'new' ramdisk driver to be automatically
employed. No small feat but that's the size of the hill
anyway. Just for grins it should be capable of detecting
a 16K cartridge there and account for it too.

The Raphael Espino ramdisk project contains some of the
best code I've ever seen BTW. But since MyDOS has it's
own internal ramdisk driver, most of his work won't work
here. It's killer stuff for Sparta and most other DOS 2.0
types though.

#3971007 Is there a 14K ramdisk for XE/XL which works under MyDOS?

Posted by 1050 on Sat Feb 24, 2018 7:48 AM

Nope, was not ported over to MyDOS as MyDOS has a
built in ramdisk driver that is capable of much larger
ramdisks. Makes it complicated to implement then.

To what purpose would such a small ramdisk be used
for anyway? I remember playing with the DOS 2.5 one,
it was just enough to whet my appetite for the real
1 meg Newell came with modified MyDOS which I began
to investigate and found I could improve upon somewhat.
Fixed a couple of bugs in MyDOS and met Mathy over
on comp.sys.8bit. And that led to beta series of

Could be done with a hack, is it worth it?

Never heard of any other 'under ROM' ramdisks for
any DOS other than that DOS 2.5 project - it did
work brilliantly too.

#3969107 Congo Bongo EXE problem

Posted by 1050 on Wed Feb 21, 2018 11:02 PM

Changes made are 26h for 94h in two places.


Attached File  Congo Bongo HomeSoft_brown.xex   16.1KB   29 downloads


#3965449 Atari 800 S-Video Problem

Posted by 1050 on Sat Feb 17, 2018 6:51 PM

EDIT: In Basic, lowering the luminance of the text seems to help with the ghosting issue.  Is there any way I can fix this at a hardware level?

Sure, you can construct a resistor network to cut
back on the level of luminance and/or chroma both.
Some insist on a 75 ohm resistor in line to 'match'
impedance to the TV/monitor but this is misapplied
#Fake News nonsense for RCA type connections in the
first place. Make it to be what works but understand
that it's probably only going to work with that
computer and that monitor both. Change one or the
other and the problem may show back up and in reverse
this time. 75 ohm inline wouldn't be a bad place to
start either. Which doesn't help any with the repeated
rumor that it's the only proper fix.

It's well known that the output levels of these
computers is quite variable, one is way to hot on
luminance and the next has chroma just a screaming.

Thanks in advance!

Most welcome - it's what we do.

#3963923 Atari 800 Xl without Basic OS

Posted by 1050 on Fri Feb 16, 2018 2:42 AM

An Atari 800 xl at the time of turn on, runs immediately to the self test. Which is the failure?

Could depend on what the results of the self test were.
You gave us nothing to go on.
How many blocks of green ram?
Does it make a difference if you boot with OPTION down?

In other case, exist an image, for example an atr or xex, for the atari basic.

Use Basicc.obj from inside this zip

I tried to use a DOS from a SIO2SD and then the B option Run cartridge, but it request me No cartrigde.

This indicates that there is no ROM in the location where BASIC
is usually found, if it's ram instead and even if it's BASIC
code as ram, it will fail with NO CARTRIDGE error report.

First time you run Basicc.obj it will autostart substituted BASIC,
after that you should do M. RUN AT ADDRESS A000 if you have
returned to DOS for example. Or you can just re-load Basicc.obj.
This is not a fix, it is only the file you asked for.

Measure voltage on pin 20 of BASIC rom with OPTION
down and then with OPTION left alone.

manterola, double check that you did not fold under a pin
on the BASIC rom chip or got it in backwards. Reseating it
should not have done that normally.

#3961310 One Last EPROM

Posted by 1050 on Tue Feb 13, 2018 12:32 AM

Well it's not a confirmed fact and it might be operator
error as in he should be entering the read section
via a different means perhaps. Don't know for sure,
but I have stated that I had something else other
than FF for first byte and Nezgar reports the same

Too odd, so I post a suspicion I'm having. I'm sure
David's still about and might investigate some. Not
prepended data either just altered to be FF for
first byte and pretty consistent about that so far.

I consider it a minor point still, at least it's
being discussed. My PC burner for example will
try to use the last file of record loaded until I
take steps to load an empty instead which then forces
it to read the actual data that is there. Cursor
might be situated upon byte #0 and one should
arrow up or otherwise take pains to not step on it.
But I don't know his software, I just know mine.

#3958798 One Last EPROM

Posted by 1050 on Sat Feb 10, 2018 4:50 PM

My take on it is no interpretation allowed, one way
commandments like a boss gives. It either gets done
or you get your paycheck somewhere else.

Magnetic strength is a function of ampere/turns, so
60 ohm winding has twice as many windings to make up
for half the current flowing thru it and that equals
the same power used and the same torque output as
the 30 ohm motor. They can do this by using smaller
wire of appropriate size. Not a doubling of gauge
thing but halving of circular mil thing which is too
often confused for millimeter instead of decadenal
area measurement based on SQUARE .001 (thousandths)
of an inch instead. So one circular mil is one square
thousandths of an inch - it can not then measure
.001 since pies are squared don't you know. Cross
sectional area measurement term.

The interwebs is completely full of garbage on the
issue and term of circular mil because even the
teachers of millennials didn't know this stuff.
They are quite convinced it has something to do with
millimeters instead of square thousandths of an inch
of a cross section of wire. Direct measurement can not
be done with circular mils, it has to be calculated.

It's best to use the full term circular mil and only
cheat between colleagues when shorthanding the term
into mils alone and never use two 'L's either. Already
too much confusion around the term circular mil, but
it has it's purpose in direct comparison to ampacity.

As in (4) 3 inch pipes can carry the same amount of
water as a single 6 inch pipe can. But 3 circular mil
wire will only carry half what a 6 circular mil
wire can. No way around the complicated maths to get to
actual dimensions and very limited field of work where
it applies as well means that a very limited few get
trained on the job as it were. Wire gauge charts
showing circular mils all but disappeared too.

Not knowing what it were just another low point in
the 'apex' of the information age.

#3953494 One Last EPROM

Posted by 1050 on Sun Feb 4, 2018 9:49 PM

USDoubler - but different from what I have.

Perhaps this is the rom used by _The Doctor_ when he
claims to have used it without the stacked ram and it
'worked just fine'?

Later versions included the extensive ram test that
I know would not allow such standard and single ram
chip use.

Mine starts with 1Dh and not FFh, have 2Ch at 0x0F00
offset too. But then blocks shift around such as to
indicate a change up in the source code at the very
least. Which begs the question why do that? Perhaps
the need for the more better extensive ram test?

Was never aware that there were two versions, but it
does appear to be the case for certain now. Thanks for
posting that as it's very interesting stuff.

They both deserve a disassembly at this point to
figure out what up and maybe why becomes obvious.

#3953461 TRACE Tulsa Regional Atari Computer Enthusiasts Club Disks

Posted by 1050 on Sun Feb 4, 2018 8:49 PM

A top slot cover could be made from another jacket
and taped onto which ever side you wanted to use for
top that day. Yes, be very afraid to grind off your
felt pads otherwise when using a single head drive.

Can not emphasize how the cleaning power of alcohol
is vastly increased with what might seem to be a minor
increase is it's formulation. Night and day difference
people. Please ONLY use 93% and higher isopropyl, you
can find it sitting right beside the 50% stuff in
many stores too.

WD-40 works too but very slowly so give it much extra
time and then rinse with alcohol swabbing as per

#3952519 Recapping my 800xl. Cap list?

Posted by 1050 on Sat Feb 3, 2018 5:20 PM

I'll also echo the non-need to do this. Only issue
with caps is in the 1050 drive and that's because of
the monster legs on those can work the solder and
fatigue it into mechanical failure. Rare is the bad
cap that has bulged from good old days when they
used the good soup inside them. Millennial cap
makers went cheap and used the weak sauce which
started the bulged cap fad in the first place.
Since then it's blamed for everything including
how the battery in my car just died.

If it were made at the turn of the century, you
might want to look up forums for that device and
read a bit more on it to see if those were stinkers
or not. I've got a couple of PC video boards with
100% ooze and bulge, but nothing like that from
the 80s or 90s.

Won't try to stop you and no, not to my knowledge
has anybody made such a list before this. Never
was a need...

#3952451 Disk Drive Problem - 1050 with 800XL

Posted by 1050 on Sat Feb 3, 2018 3:50 PM

Not really. Only two per 1050 drive but each 3086
has five transistors, any one of them can suffer from
beta decay where the gain just isn't what it was
when it was new and the performance of that circuit
is then lacking. Or outright failure which will
end the circuit's function. Only rated for 7 volts
maximum is one item of note for me, they just don't
hold up and carry their own weight it seems.

Blown diodes, bad voltage regulator, bad caps
lead the 'bad' item list with a funky 3086 next in
line. Kinda rare, but still trouble enough to just
replace if you can get them at a decent price. $10
is ridiculous, $3 is more like it. And $1 per in
50 count lots for the far visionary type.

NOS might not be the best buy as quality of silicon
used in the first generation. I would feel much
better with the more recent NTE 912 equivalent.

The usual way you find out if it is the 3086 is
when the drive starts working like new AFTER you
replace it at wit's end. So no easy way to tell.

You can play a hunch which is what I gather
koolmoecraig is doing. I would have cleaned
the switches first. If it's the switches then it's
still the switches and they can be cleaned anytime
and that's when it will start working again. No
foul, no error and it might be a good lesson learned.

#3952124 I Found Some Interesting EPROMS...

Posted by 1050 on Sat Feb 3, 2018 7:20 AM

Vast improvement just looking thru it, I did not do
a compare with what we probably already have from
other sources anyway.

1200XL.BIN should probably be renamed to be
1200XL_A.BIN since it's only the first half of the
entire OS though. 0xE000 - 0xFFFF would be the
last half. A simple DOS 2.0 save should work there
and then the stripping of six byte Atari file header
would get to that .bin file.

Overall, it looks right as rain and I'm trusting it.