Newell OSN for 400/800

[+slx]

All this is about original 400/800 "non-XL" machines:

 

I am trying to use tf_hh's 400 RAM card to best effect by burning an EPROM with Fastchip and Omnimon for the 400/800. While I have found a lot of documentation I have not been able to collect the necessary ROM files (or at least to assemble them in a form that works on Altirra before I burn them).

 

My understanding is that I need 8K of OSN OS ROM which is patched to allow, inter alia, access to Omnimon with System Reset + Option, 4K of Omnimon and (optional) 2K of FastChip which should be assembled in the following sequence:

 

• Fastchip C000-CFFF
• empty/zero D000-D800 (hardware registers)
• FP ROM D800-DFFF
• OS ROM E000-FFFF

I would be happy with a single file I can burn but short of that appreciate any vectors on where to find working ROM files.

 

There is documenation about an extended Omnimon and a combined Omnimon/ROMDOS but I understand these to require a RAMROD board that allows for bankswitching in the C000-CFFF area.

 

As I will eventually try to use these on an Incognito 800 as well, would that support bankswitching of the OSN type in the C000-CFFF area?

 

 

[Rybags]

If you find bits and pieces you can use the Windows/Dos COPY /B command to append files together. I had to do that the other day with an XEGS Rom that was out of order.

 

You can also mix and match accelerated FP routines but they'd have to be ones that fit into the original 2K if you also want OmniMon. The FP routines are platform independent though the "extra fast" ones that also have code around $CC00 would need that extra Rom on older machines.

 

In theory you could probably get the "extra fast" FP routines going - the ones that also use Rom around $CC00. You'd need to combine it with an original 800 OS or at least one that's not expecting Ominmon code at $C000. You'd then have much of the $C000 space available for something else.

[sup8pdct]

I have`only seen 2 monitor type programs for 400/800. Both use the 4K at $C000, $CFFF. One has 2 4K banks that can be selected under program control. Would say that omnimon would be similar to one of those 2. Extra hardware is required to support bank switching tho. Don't know if any emulator supports bank switching the $cxxx. Also depends on what address needs to written/read to switch banks.

 

James

[ACML]

I am also looking for the Omniview ROM image for the 400/800 that I'd like to use on tf_hh's 400 RAM card.

[1050]

Your order is somewhat whacked, but I can

understand how easy that can happen so no

worries.

 

So Fastchip is different from Fast Chip and

they work differently too. Marslett wrote

Fastchip and it's a replacement for the

standard FP math pack rom that lives at

D800-DFFF. Fast Chip is something else

that also occupies that region as well as

C000-CFFF - this one has no source, can't

find much about it and have nothing to

gauge it's speed by in the first place.

• Omni something C000-CFFF
• empty/zero D000-D800 (hardware registers)
• Fastchip D800-DFFF
• OSN ROM E000-FFFF

Is how it should be set up for the new 400 card.

Not sure where I got the ramrod OSN that the

attached burnfile contains but am thinking it

was posted in this group on the subject of the

ramrod board. It appears to contain the 8K omni

though which would require active eprom addressing

scheme and that part is unknown to me since I

don't have one of the ramrod boards set up for an

8k omni - I say that only because I don't know if

it's a combo monitor/80 column viewer and it sure

could be both. The source code for OSN calls for

OMNI only as if both are fired up with a jump to

CFF5 from OSN code. But the ramrod code I have,

has garbage there, so it's NOT clear at all if

the OSN offering here will actually work or not.

Since no emulator allows Cxxx rom, there can be

no test there that will work, it must be done

with the new 400 rom card.

 

So the first half is OSN as found on the ramrod

code and the second half is standard OS B and

you'll have to fire up Omnimon via a jump to

CFF5 which inserts it's interrupt vectors into

the interrupt table such that it should work

with normal keypresses for Omnimon from then

on? At least that's the hope I have.

 

So find enclosed what I have at the moment,

a nebulous OSN which I believe to be version

4 since it's a bit different than the version

601 source code recently found. My own Omin800

rom which was found in an 800 haul as a dismounted

eprom in a film can with nothing but a label to

tell me of what it was. No other documentation

was ever uncovered about it. I did get a ramrod

user to come back and say 'thanks, it worked a treat.'

So there is that much, and it does have working code

at CFF5 that does insert interrupt vectors and set

about to 'live' large - the 8k version in the ramrod

image had garbage there and not sure what to make of it.

 

So the DOS mode copy file1+file2 file3 method needs the

/b switch slapped up side it's head or you'll get short

builds that can't possibly work right. Enclosed find the

copy.txt that has added at the bottom the useage I used

to build the burnfile from all the parts I've been able

to gather. So now you can build it in reverse order if

that is what you want too. Make copy.txt like this:

copy /?>copy.txt

 

burnfile.zip

 

I am working on OSN version 601 but the results are

lacking the proper power up sequence. It wants to

set up interrupt vectors via OMNI branch to CFF5

before the ram has even been cleared and the OS

system properly installed. Unless Newell decided

to just plug in the proper powerup vector at FFFC

as an afterthought rather than have the code assemble

in that manner? I have more work to do in other words,

this is what I gots right now. It's likely there will

be other issues with 601 too.

[+slx]

 

burnfile.zip

 

First, a big thanks to 1050 for providing an OS N burnfile.

 

It's been quite some time but a quiet spell after Christmas has finally allowed me to burn the burnfile (my first self-burnt EPROM ever!) and complete the installation in my 400 (which I converted to PAL at the same time). It seems to work with the following effects:

• There is no "Memo Pad" on boot. I assume that space was sacrificed for extra routines. The system boots to a blank screen with a cursor.
• The screen colour is a hideous dark green instead of blue. I assume this was done on purpose to differentiate OS N?
• I can call Omnimon by jumping to $C001. I can't call it using [OPTION] + [system Reset] but as System Reset seems to be completely dead I assume that's a problem with my 400's keyboard. (see separate thread)

Would appreciate any feedback on whether that constitutes normal behavior. If it is easy to change the screen colour back from green to blue that would be nice, too. Probably just a single byte in the OS code, but which one ?

 

Is there a manual for 400/800 OS N around? Google only showed OSNXL.

[+slx]

Quick update: Checked the firmware in Altirra. No Memo Pad title either, but a darker shade of blue instead of green. Maybe a case of color pot adjustment. Guess I need to repair/replace my keyboard to get System Reset working again.

Edited December 29, 2017 by slx

[1050]

I will attest to seeing green screenshots of OSN so

I'm tending to think it's the default color scheme

there even though the code seems to be stock for that.

Same method and values for even XL/XE series too, but

there also the background and border (0x02C8 mapping

the Atari pg 64-65) is set to be black.

 

How that changes I haven't yet had the aha moment.

 

But in the file supplied above, the offset to that

data is 0x1EC9 and the next five bytes comprise

COLOR0 thru COLOR4 as shown on pg 64-65 in mapping

the Atari book. Values in hex are 28 CA 90 46 00.

Later on 06h is stuffed into 0x02C8 directly which

is still black but with more luminosity (?). I am

a bit confused, I'll admit. GTIA modes and colors

not my usual fodder either. But yes, there certainly

must be a byte responsible and I'll try to find it.

 

You are welcome and thanks so much for returning

with good news even though it sounds like a bit more

work is needed. Well, same here it seems. I did find

a bug in 601 source (such as it is) concerning this

very area just as something else that now needs my

attentions. I'll do what I can when I can.

 

So very little information exists from this era of

Atari, I haven't seen such a manual for OSN.

[+slx]

So very little information exists from this era of

Atari, I haven't seen such a manual for OSN.

 

 

Seems I was just expecting too much This file on archive.org seems to be all the manual there is. More of a hardware guide to RAMROD with a brief explanation of OS N features:

• configurable cassette baud rate
• increased keyboard repeat speed
• graphics modes 12-15
• possibility to ignore cartridges on powerup

Nothing overly exciting there, so the main reason to use it in 2017 is probably the patch allowing Omnimon to be run with [system Reset + Option] (and maybe the graphics modes for XL compatibility if you're into BASIC programming).

[+slx]

But in the file supplied above, the offset to that

data is 0x1EC9 and the next five bytes comprise

COLOR0 thru COLOR4 as shown on pg 64-65 in mapping

the Atari book. Values in hex are 28 CA 90 46 00

 

After a bit of confusion from where to count 1EC9 a simple change of $90 to $94 of byte $1ECB of the OSN file (that is the byte that will end up at $FECB) will have the system boot up in normal color.

 

Now I only need to dig up that 400 keyboard in my basement.

[1050]

I wish I could be so sure as you though, while double
tasking with 601 source I see in that code this set
of bytes instead.

FEC9 28CAB246 8680 COLRTB .BYTE $28 , $CA , $B2 , $46 , 0

And by the chart, B2h is a darker hideous green. And
I swear I've seen a screenshot of that, you are right
about hideous.

So either you are using different code than I supplied
or ??? went wrong somewheres I have no clue of. Which
of course worries me that there is a 'hidden' overwrite
function within the code that would tend to negate this
OS setup COLRTB table, since the hideous green version
appears to be in 601 version exclusively, version 2 OSN
has stock Atari table (within reason).

Mapping the Atari starting at page 163 for color tables
in decimal unfortunately. And also bottom of page 62 if

that's closer to get too. B2h = 178.

For other OS such as Puff's Ultra Speed Plus OS the values
are 28 CC 92 46 00 and the screen is noticeably bluer
while the letters are whiter and it's quite a good look
taken as a whole. At the same time you know at once this is
NOT a standard machine you are sitting in front of.

PRINT PEEK(65227)
might be useful?
65227 = 0xFECB

and then
PRINT PEEK(710)
just to be sure the overwrite isn't afoot.
710 = 0x02C6

 

0x02C6 is the Shadow for 53272 ($D018).

Thinking BASIC might inject it's own color scheme
here so maybe emulator use would be better.

For now I have no explanation of how you get the 601
green screen without some code corruption of some sort
going on. Or some yet to be uncovered overwrite going
on from somewhere. And I thought I gave it a good

look too.

As if this isn't enough, check out these dumps of
omniview which would be the file titled C000-CFFF.
http://atariage.com/forums/topic/257124-found-a-130xe-with-a-hacked-os-rom/page-2?do=findComment&comment=3915948
Taking the place of my offered Ominmon800 code.

Not actually ROM files as they contain a six byte
Atari file header which when stripped from these
files become genuine .rom or .bin files. As is they
are Atari executables without the execute part
included. They will try to load into those regions
if you use DOS to load them in a standard manner,
but since it's ROM and can't be overwritten it's a
doomed exercise in futility. These would be the
results of a standard DOS K. Save memory choice
without adding the RUN or INIT vectors to the
'addresses to save' info inputted when making these
files.

>>>>

 

Go ahead, tell me all about that guy. Good on ya

for figuring it out too.

[+slx]

I wish I could be so sure as you though, while double

tasking with 601 source I see in that code this set

of bytes instead.

 

FEC9 28CAB246 8680 COLRTB .BYTE $28 , $CA , $B2 , $46 , 0

 

And by the chart, B2h is a darker hideous green. And

I swear I've seen a screenshot of that, you are right

about hideous.

 

 

I re-checked the burnfile.zip from the post above in a hex editor and it does not contain a $28 $CA $B2 $56 sequence but has a $90 instead of the $B2. I even checked the file I actually burned (which was a combination of your burnfile and tf_hh's original 32K EPROM) to the same conclusion. $90 should be a very dark blue.

 

As one of the screws holding the hinge of the cartridge flap loosened and fell into the machine right after I had finished re-assembling the 400 I have to re-open it again anyway and will re-check the color on an LCD and a CRT screen, try to adjust the color pot on the SCCC and then decide whether to re-flash the EPROM with more than $90. I am pretty adept at 400 disassembly/re-assembly by now. This will have to wait till next year, though.

Edited December 31, 2017 by slx

[+slx]

 

PRINT PEEK(710)

just to be sure the overwrite isn't afoot.

710 = 0x02C6

 

0x02C6 is the Shadow for 53272 ($D018).

 

Thinking BASIC might inject it's own color scheme

here so maybe emulator use would be better.

POKE 710,0 used to be my first command in every session until I could program an AUTORUN.SYS to do it for me

 

AFAIK BASIC, ACTION, MAC/65, etc. all use the standard colour scheme with light blue, exactly the same as for memo pad. I believe that to be the default for the E: device.

[mechanerd]

I did dump the custom roms that I had with my 800 Ramrod board. It's an interesting combo. Someone did all the mods mentioned in the manual and included the fastmath.

I ran this dumprom utility and saved the results.

Also, just for being thorough i did the dump on the Omnimon 800 4kb eprom.

 

Enjoy!

 

AtariROMDumper.atr

OMNI800.rom

omniview800_c000.rom

[ACML]

I did dump the custom roms that I had with my 800 Ramrod board. It's an interesting combo. Someone did all the mods mentioned in the manual and included the fastmath.

I ran this dumprom utility and saved the results.

Also, just for being thorough i did the dump on the Omnimon 800 4kb eprom.

 

Enjoy!

 

mechanerd,

 

If I wanted to run a 800 with Omniview, how would I use the 4K ROM you dumped? I guess I'm asking where and how would you blend this with the 400/800 10K ROM that already exists? The 400/800 ROMs have two 4K chips and a 2K floating point chip. I want to make this a single ROM image I can burn on a 27128 (16Kx8 EPROM). I'm trying to have Omniview on a 400 with fast math.

 

• Fastchip C000-CFFF
• empty/zero D000-D800 (hardware registers)
• FP ROM D800-DFFF
• OS ROM E000-FFFF

C000 to FFFF is 16K. What are the ROM files to build this?

Edited January 30, 2018 by ACML

[mechanerd]

I don't think you can use this with the Fastchip since the Omniview rom add on is mapped to the same space. C000-CFFF . However, on the ram rod board you can pull the Omniview out and put the Omnimon in. There was also a piggyback board for the Omnimon to add to the ramrod so you could switch between the two option roms.

[ACML]

I don't think you can use this with the Fastchip since the Omniview rom add on is mapped to the same space. C000-CFFF . However, on the ram rod board you can pull the Omniview out and put the Omnimon in. There was also a piggyback board for the Omnimon to add to the ramrod so you could switch between the two option roms.

OK, that makes sense.

 

• Omniview80 C000-CFFF
• empty/zero D000-D800 (hardware registers)
• Fastchip D800-DFFF
• OSN ROM E000-FFFF

Would this work? If so, what ROM is the Fastchip ROM and what is the OSN ROM?

Edited January 31, 2018 by ACML

[+sm3]

It doesn't seem like he has posted the fastchip nor OSN ROMs. When I created my thread for this, OSN comes in 2 ROMs and the fastchip you can't just dump and burn to another ROM, it doesn't work.

 

But I'm no expert, user 1050 here on Atariage was helping me out. I never got further than using my stock math chip with OSN and an Omnirom that didn't work properly

[_The Doctor__]

There is Fast Chip and Fastchip, two different animals..

[+sm3]

There is Fast Chip and Fastchip, two different animals..

 

Oh OK, but here we are talking about Fastchip from Newell aren't we?

[1050]

It doesn't seem like he has posted the fastchip nor OSN ROMs. When I created my thread for this, OSN comes in 2 ROMs and the fastchip you can't just dump and burn to another ROM, it doesn't work.

Agree with opinion of mechanerd's offering in post #14,

the only one that looks good is

OMNI800.rom

 

Which has me as the source. It should be called Omnimon4k

since we now seem to have Omniview4k thanks to mechanerd

in another post linked to in post #11 and there his

ROM reading ATR seems to have worked. I don't have a

working Atari to know why or test how good it is

and dealing with rom issues while running an emulator

is going to be troublesome due the patches they use

etc., skewing results there. In this post at least, it

seems the ROM reading ATR didn't work so very well.

And I of course have no real clue as to why.

 

I thought we corrected my misunderstanding of what the

issue was with the math pack in another thread already?

At any rate, I was wrong we don't need a special 2716

to do that with, according to page 3 of the ramrod

instructions we only need a 350ns 2716 to burn the

code onto and bob's our uncle. So it would work just

fine, yet you keep saying it won't and I keep having to

say I was wrong about my assumptions in another thread

long ago when we didn't have good instructions for the

ramrod board which is posted as a link in post #9 here

in this thread.

 

 

But I'm no expert, user 1050 here on Atariage was helping me out. I never got further than using my stock math chip with OSN and an Omnirom that didn't work properly

Oh please, no to the Omnirom speak, it gets too confusing

already. We only had Omnimon4k at that time so that

had to be it. If you'll read the third bullet in post #6

Atariage user six can fire off his Omnimon4k by doing

a jump thru 0xC001. It may be that the often invoked

RESET+SELECT method was an addon to XL/XE version of

OmnimonXL/XE and we just didn't ever know that before.

I don't think we have instructions for 4K Omni anything

do we?

 

 

• Omniview80 C000-CFFF
• empty/zero D000-D800 (hardware registers)
• Fastchip D800-DFFF
• OSN ROM E000-FFFF

Would this work? If so, what ROM is the Fastchip ROM and what is the OSN ROM?

 

Yes it would work. Fastchip rom is in my burnfile.zip

offering in post #5. OSN V4...? is also in there.

But so far only the Atari file header version of

Omniview4k is posted under a different name in the

programming section linked to in post #11.

 

So I'll strip the header and rename it correctly

right here.

Omniview4K.bin

 

My original offering from way back, renamed

Onmimon4K.bin

 

Fastchip by Marslett

Fastchip.bin

 

And mechanerd's version of OSNE and OSNF combined

from the other thread where it did not have the

fastchip code but instead the standard math pack

code. With headers over there, here it is stripped

of math pack and headers as one OSNEF file version

who knows what? It is a different one yet so you

might give it try.

E000_FFFF.bin

 

I've been busy, I think OSNv601 is as ready as it

can be without byte for byte confirmation of

accuracy from anyone holding onto that code. This

was recreated from PDF source only so it may contain

OCR errors not yet corrected - if you find anything

you may PM me or just reply here, your choice but

I certainly want to know about it.

OSNv601.zip

 

And for those that don't want the hideous green

of OSNv601 here is transplanted US+ color

scheme which is the only hack done to it and

should be quite agreeable in appearance.

Osnf_boboscolor.bin

 

OSNv601 does seem to test for which Omni is at

0xC000-0xCFFF and does branches accordingly.

Have no clue if it's done right at all or not

and it may be that this code isn't the actual

released version in the wild - Newell may have

patched the powerup vectors to do things

differently and I have no way to test it at

the moment. Can't sit on this in the meantime

either, simply can't even suggest as to when

I'll sit behind a real working Atari ever

again.

 

Fast chip was an XL/XE thing that occupied not

only the original math pack area but also

international character set and maybe even

0xCxxx region to some extent as well. Don't

know a whole lot about it, ClausB did some

work on a version of his IIRC, but the original

seems to be untouchable as to source, concept

or anything else.

[+sm3]

Detailed post as always 1050 and yes, sorry, was a typo on the "omnirom" I meant to type Omnimon. While I was able to access the Omnimon via the specific key press, it did not work the way I was expecting (maybe wrong version and differing documentation).

[1050]

I knew what you meant, just railing against

Newell's omnipotent Omni concept and the onslaught

of confusion such a sexy name has caused me by the time

13 versions have interbred with themselves like this.

 

I'm really afraid were are going to have the same issue

with OSNv601 as to firing up things. The OS doesn't even

clear ram before the jump to the Omni region is done.

 

I don't see how that can work at all then. Vector at

0xFFFC-0xFFFD should be 25 F1 instead of 35 E9 if the

OS is to clear ram and set itself up right. But then

how to invoke things Omni? Only the people holding

the actual code can tell us this. Please send us the

last six bytes of any OSN - TIA.

[+Larry]

Was anyone successful in using the (800) Onniview or Omnimon rom dumps in the tf_hh 48K expansion board? 

 

And did anyone every run across the elusive Newell RamRod OS board? 

 

And finally, did anyone ever find the (even more elusive) RomDos version of MyDos? Of course, this was an early version of MyDos 3.0x, so it did not support more than floppies and (I think) no ramdisk.  I've never seen it -- just read about it in the early mag. advertisements.

[JR>]

I did recently (well, over a year ago actually) pick up a Ramrod Board.  I haven't really gotten beyond just verifying that it works.  It does appear to have OSN and Omnimon on EPROMS, but just the standard math pack ROM. I really need to get those dumped.

 

I plan to try the various Newell rom combos on my tf_hh 48K board when I get around to installing it, but I don't see why they wouldn't work.

 

Sigh......too many projects!